CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35852 – mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work
https://notcve.org/view.php?id=CVE-2024-35852
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled. The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle. Fix by freeing the hints if hints are associated with a work that was canceled while pending. Blame the original commit since the reliance on not having a pending work associated with hints is fragile. [1] unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: Corrige pérdida de memoria al cancelar trabajo de rehash El trabajo retrasado de rehash se reprograma con retraso si el número de créditos al final del trabajo no es negativo como supuestamente significa que la migración terminó. En caso contrario, se reprograma inmediatamente. • https://git.kernel.org/stable/c/c9c9af91f1d9a636aecc55302c792538e549a430 https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758 https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04 https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35851 – Bluetooth: qca: fix NULL-deref on non-serdev suspend
https://notcve.org/view.php?id=CVE-2024-35851
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: qca: corrige NULL-deref en suspensión sin serdev. Los controladores Qualcomm ROME se pueden registrar desde la disciplina de línea Bluetooth y en este caso el puntero HCI UART serdev es NULL. Agregue la verificación de sanidad que falta para evitar una desreferencia del puntero NULL cuando se llama a wakeup() para un controlador que no es serdev durante la suspensión. Simplemente devuelva verdadero por ahora para restaurar el comportamiento original y solucionar el problema con los kernels anteriores a 6.2, que no tienen la confirmación e9b3e5b8c657 ("Bluetooth: hci_qca: solo asigna activación con soporte de puerto serie") que causa que el problema ya ocurra en el tiempo de configuración. • https://git.kernel.org/stable/c/c1a74160eaf1ac218733b371158432b52601beff https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489 https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88 https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189 https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35849 – btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
https://notcve.org/view.php?id=CVE-2024-35849
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la fuga de información en btrfs_ioctl_logic_to_ino() Syzbot informó la siguiente fuga de información en btrfs_ioctl_logic_to_ino(): ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h: 114 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [en línea] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [en línea] btrfs_ioctl_logic_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c :904 [en línea] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h: 17 do_syscall_x64 arco/ x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [en línea] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [en línea] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc incluye /linux/slab.h:766 [en línea] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logic_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 ctl fs/ioctl.c :51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x Arco 3b50/x86/incluye /generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 de 65536 no están inicializados El acceso a la memoria de tamaño 65536 comienza en ffff888045a40000. Esto sucede porque estamos copiando una 'estructura btrfs_data_container' nuevamente al espacio de usuario. Este btrfs_data_container se asigna en 'init_data_container()' a través de kvmalloc(), que no llena la memoria con ceros. • https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772 https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86 https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6 https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6 https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54 https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35848 – eeprom: at24: fix memory corruption race condition
https://notcve.org/view.php?id=CVE-2024-35848
In the Linux kernel, the following vulnerability has been resolved: eeprom: at24: fix memory corruption race condition If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory. Move the failure point before registering the nvmem device. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: eeprom: at24: corrige la condición de ejecución por corrupción de memoria. Si no se puede acceder a la eeprom, se registrará un dispositivo nvmem, la lectura fallará y el dispositivo se apagará. Si otro controlador accede al dispositivo nvmem después del desmontaje, hará referencia a una memoria no válida. • https://git.kernel.org/stable/c/b20eb4c1f0261eebe6e1b9221c0d6e4048837778 https://git.kernel.org/stable/c/c850f71fca09ea41800ed55905980063d17e01da https://git.kernel.org/stable/c/26d32bec4c6d255a03762f33c637bfa3718be15a https://git.kernel.org/stable/c/c43e5028f5a35331eb25017f5ff6cc21735005c6 https://git.kernel.org/stable/c/2af84c46b9b8f2d6c0f88d09ee5c849ae1734676 https://git.kernel.org/stable/c/6d8b56ec0c8f30d5657382f47344a32569f7a9bc https://git.kernel.org/stable/c/f42c97027fb75776e2e9358d16bf4a99aeb04cf2 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35847 – irqchip/gic-v3-its: Prevent double free on error
https://notcve.org/view.php?id=CVE-2024-35847
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3-its: Evitar el double free en caso de error. La ruta de manejo de errores en its_vpe_irq_domain_alloc() provoca un double free cuando its_vpe_init() falla después de asignar exitosamente al menos una interrupción. Esto sucede porque its_vpe_irq_domain_free() libera las interrupciones junto con el mapa de bits del área y la vprop_page y its_vpe_irq_domain_alloc() posteriormente libera nuevamente el mapa de bits del área y la vprop_page. Solucione este problema invocando incondicionalmente its_vpe_irq_domain_free() que maneja todos los casos correctamente y eliminando el mapa de bits/vprop_page que se libera de its_vpe_irq_domain_alloc(). • https://git.kernel.org/stable/c/7d75bbb4bc1ad90386776459d37e4ddfe605671e https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662 https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52 https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438 https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9 https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792 https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fe •