{"api_version":"1","generated_at":"2026-08-24T11:46:31+00:00","cve":"CVE-2024-41009","urls":{"html":"https://cve.report/CVE-2024-41009","api":"https://cve.report/api/cve/CVE-2024-41009.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2024-41009","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2024-41009"},"summary":{"title":"bpf: Fix overrunning reservations in ringbuf","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix overrunning reservations in ringbuf\n\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\nconsumer counter to show which logical position the consumer consumed the\ndata, and producer_pos which is the producer counter denoting the amount of\ndata reserved by all producers.\n\nEach time a record is reserved, the producer that \"owns\" the record will\nsuccessfully advance producer counter. In user space each time a record is\nread, the consumer of the data advanced the consumer counter once it finished\nprocessing. Both counters are stored in separate pages so that from user\nspace, the producer counter is read-only and the consumer counter is read-write.\n\nOne aspect that simplifies and thus speeds up the implementation of both\nproducers and consumers is how the data area is mapped twice contiguously\nback-to-back in the virtual memory, allowing to not take any special measures\nfor samples that have to wrap around at the end of the circular buffer data\narea, because the next page after the last data page would be first data page\nagain, and thus the sample will still appear completely contiguous in virtual\nmemory.\n\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\nbook-keeping the length and offset, and is inaccessible to the BPF program.\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\npossible to make a second allocated memory chunk overlapping with the first\nchunk and as a result, the BPF program is now able to edit first chunk's\nheader.\n\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\nwas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\npages. This means that chunk B at [0x4000,0x4008] is chunk A's header.\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\nB modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong\npage and could cause a crash.\n\nFix it by calculating the oldest pending_pos and check whether the range\nfrom the oldest outstanding record to the newest would span beyond the ring\nbuffer size. If that is the case, then reject the request. We've tested with\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\nis still not significantly enough to matter.","state":"PUBLISHED","assigner":"Linux","published_at":"2024-07-17 07:15:01","updated_at":"2026-08-04 11:19:15"},"problem_types":["CWE-770"],"metrics":[{"version":"3.1","source":"nvd@nist.gov","type":"Primary","score":"5.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","name":"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","name":"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":["Mailing List","Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686","name":"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":["Mailing List","Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","name":"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","name":"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":["Mailing List","Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html","name":"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","name":"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":["Mailing List","Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-41009","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41009","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab be35504b959f2749bab280f4671e8df96dcf836f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab 0f98f40eb1ed52af8b81f61901b6c0289ff59de4 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab d1b9df0435bc61e0b44f578846516df8ef476686 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab 511804ab701c0503b72eac08217eabfd366ba069 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab 47416c852f2a04d348ea66ee451cbdcf8119f225 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 457f44363a8894135c85b7a9afd2bd8196db24ab cfa1a2329a691ffd991fcf7248a57d752e712881 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.8","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.8 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.10.223 5.10.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.15.164 5.15.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.97 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.37 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.9.8 6.9.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.10 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[{"cve_year":"2024","cve_id":"41009","vulnerable":"1","versionEndIncluding":"","cpe1":"cpe","cpe2":"2.3","cpe3":"o","cpe4":"linux","cpe5":"linux_kernel","cpe6":"*","cpe7":"*","cpe8":"*","cpe9":"*","cpe10":"*","cpe11":"*","cpe12":"*","cpe13":"*"}],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"providerMetadata":{"dateUpdated":"2025-11-03T21:59:13.101Z","orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE"},"references":[{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"},{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"},{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"},{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"},{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"},{"tags":["x_transferred"],"url":"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"},{"url":"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"}],"title":"CVE Program Container"},{"metrics":[{"other":{"content":{"id":"CVE-2024-41009","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2024-09-10T16:25:12.740807Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2024-09-11T17:34:06.763Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["kernel/bpf/ringbuf.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"be35504b959f2749bab280f4671e8df96dcf836f","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"},{"lessThan":"0f98f40eb1ed52af8b81f61901b6c0289ff59de4","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"},{"lessThan":"d1b9df0435bc61e0b44f578846516df8ef476686","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"},{"lessThan":"511804ab701c0503b72eac08217eabfd366ba069","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"},{"lessThan":"47416c852f2a04d348ea66ee451cbdcf8119f225","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"},{"lessThan":"cfa1a2329a691ffd991fcf7248a57d752e712881","status":"affected","version":"457f44363a8894135c85b7a9afd2bd8196db24ab","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["kernel/bpf/ringbuf.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"5.8"},{"lessThan":"5.8","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"5.10.*","status":"unaffected","version":"5.10.223","versionType":"semver"},{"lessThanOrEqual":"5.15.*","status":"unaffected","version":"5.15.164","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.97","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.37","versionType":"semver"},{"lessThanOrEqual":"6.9.*","status":"unaffected","version":"6.9.8","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"6.10","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.10.223","versionStartIncluding":"5.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.15.164","versionStartIncluding":"5.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.97","versionStartIncluding":"5.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.37","versionStartIncluding":"5.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.9.8","versionStartIncluding":"5.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.10","versionStartIncluding":"5.8","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix overrunning reservations in ringbuf\n\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\nconsumer counter to show which logical position the consumer consumed the\ndata, and producer_pos which is the producer counter denoting the amount of\ndata reserved by all producers.\n\nEach time a record is reserved, the producer that \"owns\" the record will\nsuccessfully advance producer counter. In user space each time a record is\nread, the consumer of the data advanced the consumer counter once it finished\nprocessing. Both counters are stored in separate pages so that from user\nspace, the producer counter is read-only and the consumer counter is read-write.\n\nOne aspect that simplifies and thus speeds up the implementation of both\nproducers and consumers is how the data area is mapped twice contiguously\nback-to-back in the virtual memory, allowing to not take any special measures\nfor samples that have to wrap around at the end of the circular buffer data\narea, because the next page after the last data page would be first data page\nagain, and thus the sample will still appear completely contiguous in virtual\nmemory.\n\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\nbook-keeping the length and offset, and is inaccessible to the BPF program.\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\npossible to make a second allocated memory chunk overlapping with the first\nchunk and as a result, the BPF program is now able to edit first chunk's\nheader.\n\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\nwas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\npages. This means that chunk B at [0x4000,0x4008] is chunk A's header.\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\nB modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong\npage and could cause a crash.\n\nFix it by calculating the oldest pending_pos and check whether the range\nfrom the oldest outstanding record to the newest would span beyond the ring\nbuffer size. If that is the case, then reject the request. We've tested with\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\nis still not significantly enough to matter."}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"providerMetadata":{"dateUpdated":"2026-08-04T09:27:41.714Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"},{"url":"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"},{"url":"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"},{"url":"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"},{"url":"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"},{"url":"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"}],"title":"bpf: Fix overrunning reservations in ringbuf","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2024-41009","datePublished":"2024-07-17T06:10:11.351Z","dateReserved":"2024-07-12T12:17:45.610Z","dateUpdated":"2026-08-04T09:27:41.714Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2024-07-17 07:15:01","lastModifiedDate":"2026-08-04 11:19:15","problem_types":["CWE-770"],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9},{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2024-09-10T16:25:12.740807Z","id":"CVE-2024-41009","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.8","versionEndExcluding":"6.1.97","matchCriteriaId":"5F2E2CF9-E512-4F81-AD6C-400701BDBF04"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.6.37","matchCriteriaId":"D72E033B-5323-4C4D-8818-36E1EBC3535F"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.9.8","matchCriteriaId":"E95105F2-32E3-4C5F-9D18-7AEFD0E6275C"}]}]}]},"legacy_mitre":{"record":{"CveYear":"2024","CveId":"41009","Ordinal":"1","Title":"bpf: Fix overrunning reservations in ringbuf","CVE":"CVE-2024-41009","Year":"2024"},"notes":[{"CveYear":"2024","CveId":"41009","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix overrunning reservations in ringbuf\n\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\nconsumer counter to show which logical position the consumer consumed the\ndata, and producer_pos which is the producer counter denoting the amount of\ndata reserved by all producers.\n\nEach time a record is reserved, the producer that \"owns\" the record will\nsuccessfully advance producer counter. In user space each time a record is\nread, the consumer of the data advanced the consumer counter once it finished\nprocessing. Both counters are stored in separate pages so that from user\nspace, the producer counter is read-only and the consumer counter is read-write.\n\nOne aspect that simplifies and thus speeds up the implementation of both\nproducers and consumers is how the data area is mapped twice contiguously\nback-to-back in the virtual memory, allowing to not take any special measures\nfor samples that have to wrap around at the end of the circular buffer data\narea, because the next page after the last data page would be first data page\nagain, and thus the sample will still appear completely contiguous in virtual\nmemory.\n\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\nbook-keeping the length and offset, and is inaccessible to the BPF program.\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\npossible to make a second allocated memory chunk overlapping with the first\nchunk and as a result, the BPF program is now able to edit first chunk's\nheader.\n\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\nwas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\npages. This means that chunk B at [0x4000,0x4008] is chunk A's header.\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\nB modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong\npage and could cause a crash.\n\nFix it by calculating the oldest pending_pos and check whether the range\nfrom the oldest outstanding record to the newest would span beyond the ring\nbuffer size. If that is the case, then reject the request. We've tested with\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\nis still not significantly enough to matter.","Type":"Description","Title":"bpf: Fix overrunning reservations in ringbuf"}]}}}