CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35862 – smb: client: fix potential UAF in smb2_is_network_name_deleted()
https://notcve.org/view.php?id=CVE-2024-35862
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_network_name_deleted() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: corrige UAF potencial en smb2_is_network_name_deleted() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF. • https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01 https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645 https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35861 – smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect()
https://notcve.org/view.php?id=CVE-2024-35861
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en cifs_signal_cifsd_for_reconnect() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF. • https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4 https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1 https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f •
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: -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 •