CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38663 – blk-cgroup: fix list corruption from resetting io stat
https://notcve.org/view.php?id=CVE-2024-38663
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24 https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9 https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791 https://access.redhat.com/security/cve/CVE-2024-38663 https://bugzilla.redhat.com/show_bug.cgi?id=2294225 • CWE-665: Improper Initialization •
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 • 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') •