{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-41009", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-07-12T12:17:45.610Z", "datePublished": "2024-07-17T06:10:11.351Z", "dateUpdated": "2024-11-05T09:34:57.113Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:34:57.113Z"}, "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."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/bpf/ringbuf.c"], "versions": [{"version": "457f44363a88", "lessThan": "be35504b959f", "status": "affected", "versionType": "git"}, {"version": "457f44363a88", "lessThan": "0f98f40eb1ed", "status": "affected", "versionType": "git"}, {"version": "457f44363a88", "lessThan": "d1b9df0435bc", "status": "affected", "versionType": "git"}, {"version": "457f44363a88", "lessThan": "511804ab701c", "status": "affected", "versionType": "git"}, {"version": "457f44363a88", "lessThan": "47416c852f2a", "status": "affected", "versionType": "git"}, {"version": "457f44363a88", "lessThan": "cfa1a2329a69", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/bpf/ringbuf.c"], "versions": [{"version": "5.8", "status": "affected"}, {"version": "0", "lessThan": "5.8", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.223", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.164", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.97", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.37", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.9.8", "lessThanOrEqual": "6.9.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.10", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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-9e1c9544281a"}}, "adp": [{"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T04:39:56.138Z"}, "title": "CVE Program Container", "references": [{"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", "tags": ["x_transferred"]}]}, {"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-41009", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T16:25:12.740807Z"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T17:34:06.763Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"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", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T04:39:56.138Z"}}, {"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-41009", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T16:25:12.740807Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T12:42:20.725Z"}}], "cna": {"title": "bpf: Fix overrunning reservations in ringbuf", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "457f44363a88", "lessThan": "be35504b959f", "versionType": "git"}, {"status": "affected", "version": "457f44363a88", "lessThan": "0f98f40eb1ed", "versionType": "git"}, {"status": "affected", "version": "457f44363a88", "lessThan": "d1b9df0435bc", "versionType": "git"}, {"status": "affected", "version": "457f44363a88", "lessThan": "511804ab701c", "versionType": "git"}, {"status": "affected", "version": "457f44363a88", "lessThan": "47416c852f2a", "versionType": "git"}, {"status": "affected", "version": "457f44363a88", "lessThan": "cfa1a2329a69", "versionType": "git"}], "programFiles": ["kernel/bpf/ringbuf.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.8"}, {"status": "unaffected", "version": "0", "lessThan": "5.8", "versionType": "custom"}, {"status": "unaffected", "version": "5.10.223", "versionType": "custom", "lessThanOrEqual": "5.10.*"}, {"status": "unaffected", "version": "5.15.164", "versionType": "custom", "lessThanOrEqual": "5.15.*"}, {"status": "unaffected", "version": "6.1.97", "versionType": "custom", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.6.37", "versionType": "custom", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.9.8", "versionType": "custom", "lessThanOrEqual": "6.9.*"}, {"status": "unaffected", "version": "6.10", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["kernel/bpf/ringbuf.c"], "defaultStatus": "affected"}], "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"}], "x_generator": {"engine": "bippy-c9c4e1df01b2"}, "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."}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-07-29T06:28:30.829Z"}}}, "cveMetadata": {"cveId": "CVE-2024-41009", "state": "PUBLISHED", "dateUpdated": "2024-09-11T17:34:06.763Z", "dateReserved": "2024-07-12T12:17:45.610Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-07-17T06:10:11.351Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "5F2E2CF9-E512-4F81-AD6C-400701BDBF04", "versionEndExcluding": "6.1.97", "versionStartIncluding": "5.8", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "D72E033B-5323-4C4D-8818-36E1EBC3535F", "versionEndExcluding": "6.6.37", "versionStartIncluding": "6.2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "E95105F2-32E3-4C5F-9D18-7AEFD0E6275C", "versionEndExcluding": "6.9.8", "versionStartIncluding": "6.7", "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."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige el exceso de reservas en ringbuf. El b\u00fafer de anillo BPF se implementa internamente como un b\u00fafer circular de tama\u00f1o potencia de 2, con dos contadores l\u00f3gicos y en constante aumento: consumer_pos es el consumidor contador para mostrar en qu\u00e9 posici\u00f3n l\u00f3gica el consumidor consumi\u00f3 los datos, y productor_pos, que es el contador del productor que indica la cantidad de datos reservados por todos los productores. Cada vez que se reserva un registro, el productor \"due\u00f1o\" del registro avanzar\u00e1 exitosamente el contador de productores. En el espacio de usuario, cada vez que se lee un registro, el consumidor de los datos avanza el contador del consumidor una vez que finaliza el procesamiento. Ambos contadores se almacenan en p\u00e1ginas separadas de modo que, desde el espacio del usuario, el contador del productor sea de solo lectura y el contador del consumidor sea de lectura y escritura. Un aspecto que simplifica y, por lo tanto, acelera la implementaci\u00f3n tanto de productores como de consumidores es c\u00f3mo el \u00e1rea de datos se mapea dos veces de forma contigua y consecutiva en la memoria virtual, lo que permite no tomar medidas especiales para las muestras que tienen que envolverse en el mismo lugar. al final del \u00e1rea de datos del b\u00fafer circular, porque la p\u00e1gina siguiente despu\u00e9s de la \u00faltima p\u00e1gina de datos volver\u00eda a ser la primera p\u00e1gina de datos y, por lo tanto, la muestra seguir\u00e1 apareciendo completamente contigua en la memoria virtual. Cada registro tiene una estructura bpf_ringbuf_hdr { u32 len; u32 p\u00e1gina_apagada; } encabezado para la contabilidad de la longitud y el desplazamiento, y es inaccesible para el programa BPF. Ayudantes como bpf_ringbuf_reserve() devuelven `(void *)hdr + BPF_RINGBUF_HDR_SZ` para que lo use el programa BPF. Bing-Jhong y Muhammad informaron que, sin embargo, es posible hacer que un segundo fragmento de memoria asignado se superponga con el primer fragmento y, como resultado, el programa BPF ahora puede editar el encabezado del primer fragmento. Por ejemplo, considere la creaci\u00f3n de un mapa BPF_MAP_TYPE_RINGBUF con un tama\u00f1o de 0x4000. A continuaci\u00f3n, consumer_pos se modifica a 0x3000 /antes/ se realiza una llamada a bpf_ringbuf_reserve(). Esto asignar\u00e1 un fragmento A, que est\u00e1 en [0x0,0x3008], y el programa BPF podr\u00e1 editar [0x8,0x3008]. Ahora, asignemos un fragmento B con tama\u00f1o 0x3000. Esto tendr\u00e1 \u00e9xito porque consumer_pos se edit\u00f3 con anticipaci\u00f3n para pasar la verificaci\u00f3n `new_prod_pos - cons_pos > rb->mask`. El fragmento B estar\u00e1 en el rango [0x3008,0x6010] y el programa BPF podr\u00e1 editar [0x3010,0x6010]. Debido al dise\u00f1o de la memoria del b\u00fafer en anillo mencionado anteriormente, los rangos [0x0,0x4000] y [0x4000,0x8000] apuntan a las mismas p\u00e1ginas de datos. Esto significa que el fragmento B en [0x4000,0x4008] es el encabezado del fragmento A. bpf_ringbuf_submit() / bpf_ringbuf_discard() usa el pg_off del encabezado para luego ubicar el bpf_ringbuf a trav\u00e9s de bpf_ringbuf_restore_from_rec(). Una vez que el fragmento B modific\u00f3 el encabezado del fragmento A, bpf_ringbuf_commit() hace referencia a la p\u00e1gina incorrecta y podr\u00eda causar un bloqueo. Solucionelo calculando el pendiente_pos m\u00e1s antiguo y verifique si el rango desde el registro pendiente m\u00e1s antiguo hasta el m\u00e1s nuevo abarcar\u00eda m\u00e1s all\u00e1 del tama\u00f1o del b\u00fafer circular. Si ese es el caso, rechace la solicitud. Hemos probado con el punto de referencia del b\u00fafer de anillo en las autopruebas de BPF (./benchs/run_bench_ringbufs.sh) antes/despu\u00e9s de la correcci\u00f3n y, aunque parece un poco m\u00e1s lento en algunos puntos de referencia, todav\u00eda no es lo suficientemente significativo como para importar."}], "id": "CVE-2024-41009", "lastModified": "2024-11-21T09:32:03.470", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-07-17T07:15:01.973", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Mailing List", "Patch"], "url": "https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-770"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"affected_release": [{"advisory": "RHSA-2024:8870", "cpe": "cpe:/a:redhat:enterprise_linux:8::nfv", "package": "kernel-rt-0:4.18.0-553.27.1.rt7.368.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-11-05T00:00:00Z"}, {"advisory": "RHSA-2024:8856", "cpe": "cpe:/o:redhat:enterprise_linux:8", "package": "kernel-0:4.18.0-553.27.1.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-11-05T00:00:00Z"}, {"advisory": "RHSA-2024:6753", "cpe": "cpe:/o:redhat:rhel_aus:8.6", "package": "kernel-0:4.18.0-372.123.1.el8_6", "product_name": "Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support", "release_date": "2024-09-18T00:00:00Z"}, {"advisory": "RHSA-2024:6753", "cpe": "cpe:/o:redhat:rhel_tus:8.6", "package": "kernel-0:4.18.0-372.123.1.el8_6", "product_name": "Red Hat Enterprise Linux 8.6 Telecommunications Update Service", "release_date": "2024-09-18T00:00:00Z"}, {"advisory": "RHSA-2024:6753", "cpe": "cpe:/o:redhat:rhel_e4s:8.6", "package": "kernel-0:4.18.0-372.123.1.el8_6", "product_name": "Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions", "release_date": "2024-09-18T00:00:00Z"}], "bugzilla": {"description": "kernel: bpf: Fix overrunning reservations in ringbuf", "id": "2298412", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2298412"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.4", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "verified"}, "cwe": "CWE-121", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbpf: Fix overrunning reservations in ringbuf\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.\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.\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.\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.\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.\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.", "An out-of-bounds memory access flaw was found in the Linux kernel\u2019s BPF subsystem. This flaw allows a local user to crash the system."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability."}, "name": "CVE-2024-41009", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Will not fix", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-07-17T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-41009\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-41009\nhttps://lore.kernel.org/linux-cve-announce/2024071715-CVE-2024-41009-cac5@gregkh/T"], "threat_severity": "Moderate", "upstream_fix": "kernel 6.1.97, kernel 6.6.37, kernel 6.9.8, kernel 6.10"}