CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26850 – mm/debug_vm_pgtable: fix BUG_ON with pud advanced test
https://notcve.org/view.php?id=CVE-2024-26850
In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: fix BUG_ON with pud advanced test Architectures like powerpc add debug checks to ensure we find only devmap PUD pte entries. These debug checks are only done with CONFIG_DEBUG_VM. This patch marks the ptes used for PUD advanced test devmap pte entries so that we don't hit on debug checks on architecture like ppc64 as below. WARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radix_pgtable.c:1382 radix__pud_hugepage_update+0x38/0x138 .... NIP [c0000000000a7004] radix__pud_hugepage_update+0x38/0x138 LR [c0000000000a77a8] radix__pudp_huge_get_and_clear+0x28/0x60 Call Trace: [c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable) [c000000004a2f980] [000d34c100000000] 0xd34c100000000 [c000000004a2f9a0] [c00000000206ba98] pud_advanced_tests+0x118/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 Also kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202! .... NIP [c000000000096510] pudp_huge_get_and_clear_full+0x98/0x174 LR [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 Call Trace: [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable) [c000000004a2f9a0] [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/debug_vm_pgtable: corrige BUG_ON con la prueba avanzada de pud. Las arquitecturas como powerpc agregan comprobaciones de depuración para garantizar que solo encontremos entradas devmap PUD pte. Estas comprobaciones de depuración sólo se realizan con CONFIG_DEBUG_VM. • https://git.kernel.org/stable/c/27af67f35631ac4b61b5e4455b44c9aee8d2cc4b https://git.kernel.org/stable/c/d2a9510c0e39d06f5544075c13040407bdbf2803 https://git.kernel.org/stable/c/eeeddf85fc58d48c58ad916e4ca12363ebd8ab21 https://git.kernel.org/stable/c/720da1e593b85a550593b415bf1d79a053133451 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26849 – netlink: add nla be16/32 types to minlen array
https://notcve.org/view.php?id=CVE-2024-26849
In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: agregue tipos nla be16/32 a la matriz minlen ERROR: KMSAN: valor uninit en nla_validate_range_unsigned lib/nlattr.c:222 [en línea] ERROR: KMSAN: valor uninit en nla_validate_int_range lib/nlattr.c:336 [en línea] ERROR: KMSAN: valor uninit en validar_nla lib/nlattr.c:575 [en línea] ERROR: KMSAN: valor uninit en __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [en línea] nla_validate_int_range lib/nlattr.c:336 [en línea] validar_nla lib/nlattr.c:575 [en línea] ... El mensaje en cuestión coincide con esta política: [NFTA_TARGET_REV] = NLA_POLICY_MAX( NLA_BE32, 255), pero debido a que el tamaño de NLA_BE32 en la matriz minlen es 0, el código de validación leerá más allá del atributo con formato incorrecto (demasiado pequeño). Nota: También faltan otros atributos, por ejemplo, BITFIELD32, SINT, UINT...: probablemente también deberían agregarse. • https://git.kernel.org/stable/c/ecaf75ffd5f5db320d8b1da0198eef5a5ce64a3f https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32 https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2024-26848 – afs: Fix endless loop in directory parsing
https://notcve.org/view.php?id=CVE-2024-26848
In the Linux kernel, the following vulnerability has been resolved: afs: Fix endless loop in directory parsing If a directory has a block with only ".__afsXXXX" files in it (from uncompleted silly-rename), these .__afsXXXX files are skipped but without advancing the file position in the dir_context. This leads to afs_dir_iterate() repeating the block again and again. Fix this by making the code that skips the .__afsXXXX file also manually advance the file position. The symptoms are a soft lookup: watchdog: BUG: soft lockup - CPU#3 stuck for 52s! • https://git.kernel.org/stable/c/01d15b68f0418382626792ab35b3fa97a1d406ea https://git.kernel.org/stable/c/8499e2f1218ee8d3029360a10001a6374dd135b7 https://git.kernel.org/stable/c/21a2115e0ca0c1b6b1b105fbc761acd9ab93adcd https://git.kernel.org/stable/c/ab49164c60803d5f637fa9643270db9f459d852c https://git.kernel.org/stable/c/a53411e805e02d813b2f2fd2c9d6eaca1d37fb08 https://git.kernel.org/stable/c/fa70c6954aabbfbca1fe39b9b60f82cf2e8cec38 https://git.kernel.org/stable/c/57e9d49c54528c49b8bffe6d99d782ea051ea534 https://git.kernel.org/stable/c/5c78be006ed9cb735ac2abf4fd64f3f4e •
CVSS: 5.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26847 – powerpc/rtas: use correct function name for resetting TCE tables
https://notcve.org/view.php?id=CVE-2024-26847
In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: use correct function name for resetting TCE tables The PAPR spec spells the function name as "ibm,reset-pe-dma-windows" but in practice firmware uses the singular form: "ibm,reset-pe-dma-window" in the device tree. Since we have the wrong spelling in the RTAS function table, reverse lookups (token -> name) fail and warn: unexpected failed lookup for token 86 WARNING: CPU: 1 PID: 545 at arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4 CPU: 1 PID: 545 Comm: systemd-udevd Not tainted 6.8.0-rc4 #30 Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NL1060_028) hv:phyp pSeries NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4 LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4 Call Trace: __do_enter_rtas_trace+0x2a0/0x2b4 (unreliable) rtas_call+0x1f8/0x3e0 enable_ddw.constprop.0+0x4d0/0xc84 dma_iommu_dma_supported+0xe8/0x24c dma_set_mask+0x5c/0xd8 mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core] probe_one+0xfc/0x32c [mlx5_core] local_pci_probe+0x68/0x12c pci_call_probe+0x68/0x1ec pci_device_probe+0xbc/0x1a8 really_probe+0x104/0x570 __driver_probe_device+0xb8/0x224 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x120 driver_attach+0x34/0x48 bus_add_driver+0x174/0x304 driver_register+0x8c/0x1c4 __pci_register_driver+0x68/0x7c mlx5_init+0xb8/0x118 [mlx5_core] do_one_initcall+0x60/0x388 do_init_module+0x7c/0x2a4 init_module_from_file+0xb4/0x108 idempotent_init_module+0x184/0x34c sys_finit_module+0x90/0x114 And oopses are possible when lockdep is enabled or the RTAS tracepoints are active, since those paths dereference the result of the lookup. Use the correct spelling to match firmware's behavior, adjusting the related constants to match. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: use el nombre de función correcto para restablecer las tablas TCE La especificación PAPR escribe el nombre de la función como "ibm,reset-pe-dma-windows" pero en la práctica el firmware usa el singular formulario: "ibm,reset-pe-dma-window" en el árbol de dispositivos. Dado que tenemos una ortografía incorrecta en la tabla de funciones RTAS, las búsquedas inversas (token -> nombre) fallan y advierten: búsqueda fallida inesperada del token 86 ADVERTENCIA: CPU: 1 PID: 545 en arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4 cpu: 1 pid: 545 com: systemd-udevd no contaminado 6.8.0-rc4 #30 Nombre de hardware: IBM, 9105-22A Power10 (RAW) 0x800200 0xf000006 de: IBM, FW1060.00 (NL10606060) :phyp pSeries NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4 LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4 Seguimiento de llamadas: __do_enter_rtas_trace+0x2a0/0x2b4 (no confiable) tas_call+0x1f8/0x3e0 enable_ddw.constprop.0+0x4d0/0xc84 dma_iommu_dma_supported+0xe8/ 0x24c dma_set_mask+0x5c/0xd8 mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core] probe_one+0xfc/0x32c [mlx5_core] local_pci_probe+0x68/0x12c pci_call_probe+0x68/0x1ec pci_device_probe+0xbc /0x1a8 realmente_probe+0x104/0x570 __driver_probe_device+0xb8/ 0x224 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x120 driver_attach+0x34/0x48 bus_add_driver+0x174/0x304 driver_register+0x8c/0x1c4 __pci_register_driver+0x68 /0x7c mlx5_init+0xb8/0x118 [mlx5_core] do_one_initcall+0x60/0x388 do_init_module +0x7c/0x2a4 init_module_from_file+0xb4/0x108 idempotent_init_module+0x184/0x34c sys_finit_module+0x90/0x114 Y es posible que haya errores cuando lockdep está habilitado o los puntos de seguimiento RTAS están activos, ya que esas rutas eliminan la referencia al resultado de la búsqueda. Utilice la ortografía correcta para que coincida con el comportamiento del firmware, ajustando las constantes relacionadas para que coincidan. • https://git.kernel.org/stable/c/8252b88294d2a744df6e3c6d85909ade403a5f2c https://git.kernel.org/stable/c/6b6282d56b14879124416a23837af9bd52ae2dfb https://git.kernel.org/stable/c/dd63817baf334888289877ab1db1d866af2a6479 https://git.kernel.org/stable/c/fad87dbd48156ab940538f052f1820f4b6ed2819 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26846 – nvme-fc: do not wait in vain when unloading module
https://notcve.org/view.php?id=CVE-2024-26846
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. • https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2 https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17 https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9 https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67 https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-415: Double Free •