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: 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 • 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52698 – calipso: fix memory leak in netlbl_calipso_add_pass()
https://notcve.org/view.php?id=CVE-2023-52698
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: calipso: corrige la pérdida de memoria en netlbl_calipso_add_pass() Si la compatibilidad con IPv6 está deshabilitada en el arranque (ipv6.disable=1), no se llama a la función calipso_init() -> netlbl_calipso_ops_register() y la función netlbl_calipso_ops_get() siempre devuelve NULL. En este caso, la función netlbl_calipso_add_pass() asigna memoria para la variable doi_def pero no la libera con calipso_doi_free(). ERROR: pérdida de memoria, objeto sin referencia 0xffff888011d68180 (tamaño 64): comunicación "syz-executor.1", pid 10746, jiffies 4295410986 (edad 17,928 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. ... seguimiento: [<...>] kmalloc include/linux/slab.h:552 [en línea] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [en línea] [<... • https://git.kernel.org/stable/c/cb72d38211eacda2dd90b09540542b6582da614e https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53 https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01 https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149 https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031 https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52693 – ACPI: video: check for error while searching for backlight device parent
https://notcve.org/view.php?id=CVE-2023-52693
In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: vídeo: comprueba si hay errores al buscar el dispositivo de retroiluminación principal. Si la llamada acpi_get_parent() en acpi_video_dev_register_backlight() fallo, por ejemplo, porque acpi_ut_acquire_mutex() fallo dentro de acpi_get_parent), esto puede provocar que se pase el identificador acpi_parent incorrecto (no inicializado) a acpi_get_pci_dev() para detectar el dispositivo pci principal. Verifique el resultado de acpi_get_parent() y configure el dispositivo principal solo en caso de éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/9661e92c10a9775243c1ecb73373528ed8725a10 https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8 https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3 https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95 https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852 •