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 •
CVSS: 6.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35843 – iommu/vt-d: Use device rbtree in iopf reporting path
https://notcve.org/view.php?id=CVE-2024-35843
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. • https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15 https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a https://access.redhat.com/security/cve/CVE-2024-35843 https://bugzilla.redhat.com/show_bug.cgi?id=2281276 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35839 – netfilter: bridge: replace physindev with physinif in nf_bridge_info
https://notcve.org/view.php?id=CVE-2024-35839
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb. • https://git.kernel.org/stable/c/c4e70a87d975d1f561a00abfe2d3cefa2a486c95 https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547 https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86 https://access.redhat.com/security/cve/CVE-2024-35839 https://bugzilla.redhat.com/show_bug.cgi?id=2281284 •