CVE-2024-41009
Linux Kernel BPF RingBuf Overwrite Vulnerability
Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
INFO
Published Date :
July 17, 2024, 7:15 a.m.
Last Modified :
Nov. 21, 2024, 9:32 a.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
3.6
Exploitability Score :
1.8
Public PoC/Exploit Available at Github
CVE-2024-41009 has a 1 public PoC/Exploit
available at Github.
Go to the Public Exploits
tab to see the list.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2024-41009
.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
A collection of links related to Linux kernel security and exploitation
linux-kernel kernel-exploitation exploit privilege-escalation security
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2024-41009
vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2024-41009
vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
Nov. 21, 2024
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4 Added Reference https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225 Added Reference https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069 Added Reference https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f Added Reference https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881 Added Reference https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686 -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jul. 29, 2024
Action Type Old Value New Value Added Reference kernel.org https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4 [No types assigned] -
Initial Analysis by [email protected]
Jul. 19, 2024
Action Type Old Value New Value Added CVSS V3.1 NIST AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Changed Reference Type https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225 No Types Assigned https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225 Mailing List, Patch Changed Reference Type https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069 No Types Assigned https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069 Mailing List, Patch Changed Reference Type https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881 No Types Assigned https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881 Mailing List, Patch Changed Reference Type https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686 No Types Assigned https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686 Mailing List, Patch Added CWE NIST CWE-770 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.8 up to (excluding) 6.1.97 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.37 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.9.8 -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jul. 17, 2024
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Added Reference kernel.org https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881 [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2024-41009
is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2024-41009
weaknesses.