CVSS: 8.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38384 – blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
https://notcve.org/view.php?id=CVE-2024-38384
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from reorder of WRITE ->lqueued __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrupción de la lista de arreglos debido al reordenamiento de WRITE ->lqueued __blkcg_rstat_flush() se puede ejecutar en cualquier momento, especialmente cuando se está ejecutando blk_cgroup_bio_start. Si la ESCRITURA de `->lqueued` se reordena con la READ de 'bisc->lnode.next' en el bucle de __blkcg_rstat_flush(), se puede asignar `next_bisc` agregando una instancia de estadística en blk_cgroup_bio_start(), entonces el La lista local en __blkcg_rstat_flush() podría estar dañada. Solucione el problema agregando una barrera. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/714e59b5456e4d6e4295a9968c564abe193f461c https://git.kernel.org/stable/c/785298ab6b802afa75089239266b6bbea590809c https://git.kernel.org/stable/c/d0aac2363549e12cc79b8e285f13d5a9f42fd08e https://access.redhat.com/security/cve/CVE-2024-38384 https://bugzilla.redhat.com/show_bug.cgi?id=2294220 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-400: Uncontrolled Resource Consumption •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36481 – tracing/probes: fix error check in parse_btf_field()
https://notcve.org/view.php?id=CVE-2024-36481
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: fix error check in parse_btf_field() btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo/sondas: corrección de verificación de errores en parse_btf_field() btf_find_struct_member() puede devolver NULL o un error a través de la macro ERR_PTR(). Sin embargo, su llamador en parse_btf_field() solo verifica la condición NULL. • https://git.kernel.org/stable/c/c440adfbe30257dde905adc1fce51131145f7245 https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0 https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb • CWE-754: Improper Check for Unusual or Exceptional Conditions •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36477 – tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer
https://notcve.org/view.php?id=CVE-2024-36477
In the Linux kernel, the following vulnerability has been resolved: tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm_tis_spi: Cuenta para el encabezado SPI al asignar el búfer de transferencia TPM SPI El mecanismo de transferencia TPM SPI utiliza MAX_SPI_FRAMESIZE para calcular la longitud máxima de transferencia y el tamaño del búfer de transferencia. Como tal, no tiene en cuenta los 4 bytes del encabezado que antepone el marco de datos SPI. • https://git.kernel.org/stable/c/a86a42ac2bd652fdc7836a9d880c306a2485c142 https://git.kernel.org/stable/c/1547183852dcdfcc25878db7dd3620509217b0cd https://git.kernel.org/stable/c/de13c56f99477b56980c7e00b09c776d16b7563d https://git.kernel.org/stable/c/195aba96b854dd664768f382cd1db375d8181f88 https://access.redhat.com/security/cve/CVE-2024-36477 https://bugzilla.redhat.com/show_bug.cgi?id=2293639 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36288 – SUNRPC: Fix loop termination condition in gss_free_in_token_pages()
https://notcve.org/view.php?id=CVE-2024-36288
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix loop termination condition in gss_free_in_token_pages() The in_token->pages[] array is not NULL terminated. This results in the following KASAN splat: KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: corrigió la condición de terminación del bucle en gss_free_in_token_pages() La matriz in_token->pages[] no tiene terminación NULL. Esto da como resultado el siguiente símbolo KASAN: KASAN: quizás acceso a memoria salvaje en el rango [0x04a2013400000008-0x04a201340000000f] • https://git.kernel.org/stable/c/8ca148915670a2921afcc255af9e1dc80f37b052 https://git.kernel.org/stable/c/a3c1afd5d7ad59e34a275d80c428952f83c8c1f0 https://git.kernel.org/stable/c/0a1cb0c6102bb4fd310243588d39461da49497ad https://git.kernel.org/stable/c/57ff6c0a175930856213b2aa39f8c845a53e5b1c https://git.kernel.org/stable/c/6ed45d20d30005bed94c8c527ce51d5ad8121018 https://git.kernel.org/stable/c/4cefcd0af7458bdeff56a9d8dfc6868ce23d128a https://git.kernel.org/stable/c/b4878ea99f2b40ef1925720b1b4ca7f4af1ba785 https://git.kernel.org/stable/c/f9977e4e0cd98a5f06f2492b4f3547db5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-34777 – dma-mapping: benchmark: fix node id validation
https://notcve.org/view.php?id=CVE-2024-34777
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: fix node id validation While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org). • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf https://git.kernel.org/stable/c/35d31c8bd4722b107f5a2f5ddddce839de04b936 https://git.kernel.org/stable/c/c57874265a3c5206d7aece3793bb2fc9abcd7570 https://git.kernel.org/stable/c/34a816d8735f3924b74be8e5bf766ade1f3bd10b https://git.kernel.org/stable/c/63e7e05a48a35308aeddd7ecccb68363a5988e87 https://git.kernel.org/stable/c/1ff05e723f7ca30644b8ec3fb093f16312e408ad •