CVSS: -EPSS: 0%CPEs: 15EXPL: 0CVE-2024-41035 – USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
https://notcve.org/view.php?id=CVE-2024-41035
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. • https://git.kernel.org/stable/c/0a8fd1346254974c3a852338508e4a4cddbb35f1 https://git.kernel.org/stable/c/c3726b442527ab31c7110d0445411f5b5343db01 https://git.kernel.org/stable/c/15668b4354b38b41b316571deed2763d631b2977 https://git.kernel.org/stable/c/8597a9245181656ae2ef341906e5f40af323fbca https://git.kernel.org/stable/c/264024a2676ba7d91fe7b1713b2c32d1b0b508cb https://git.kernel.org/stable/c/b0de742a1be16b76b534d088682f18cf57f012d2 https://git.kernel.org/stable/c/7cc00abef071a8a7d0f4457b7afa2f57f683d83f https://git.kernel.org/stable/c/05b0f2fc3c2f9efda47439557e0d51fac •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41034 – nilfs2: fix kernel bug on rename operation of broken directory
https://notcve.org/view.php?id=CVE-2024-41034
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug on rename operation of broken directory Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size. This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories. Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot(). • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/ff9767ba2cb949701e45e6e4287f8af82986b703 https://git.kernel.org/stable/c/24c1c8566a9b6be51f5347be2ea76e25fc82b11e https://git.kernel.org/stable/c/a9a466a69b85059b341239766a10efdd3ee68a4b https://git.kernel.org/stable/c/7000b438dda9d0f41a956fc9bffed92d2eb6be0d https://git.kernel.org/stable/c/1a8879c0771a68d70ee2e5e66eea34207e8c6231 https://git.kernel.org/stable/c/60f61514374e4a0c3b65b08c6024dd7e26150bfd https://git.kernel.org/stable/c/298cd810d7fb687c90a14d8f9fd1b8719 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41030 – ksmbd: discard write access to the directory open
https://notcve.org/view.php?id=CVE-2024-41030
In the Linux kernel, the following vulnerability has been resolved: ksmbd: discard write access to the directory open may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory. list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 • https://git.kernel.org/stable/c/66cf853e1c7a2407f15d9f7aaa3e47d61745e361 https://git.kernel.org/stable/c/9e84b1ba5c98fb5c9f869c85db1d870354613baa https://git.kernel.org/stable/c/198498b2049c0f11f7670be6974570e02b0cc035 https://git.kernel.org/stable/c/e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-41020 – filelock: Fix fcntl/close race recovery compat path
https://notcve.org/view.php?id=CVE-2024-41020
In the Linux kernel, the following vulnerability has been resolved: filelock: Fix fcntl/close race recovery compat path When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. An LSM can prevent the fcntl/close race cleanup path in fcntl_setlk() from working, leading to use-after-free read in lock_get_status() when reading /proc/locks. • https://git.kernel.org/stable/c/c293621bbf678a3d85e3ed721c3921c8a670610d https://git.kernel.org/stable/c/a561145f3ae973ebf3e0aee41624e92a6c5cb38d https://git.kernel.org/stable/c/4c43ad4ab41602201d34c66ac62130fe339d686f https://git.kernel.org/stable/c/911cc83e56a2de5a40758766c6a70d6998248860 https://git.kernel.org/stable/c/53e21cfa68a7d12de378b7116c75571f73e0dfa2 https://git.kernel.org/stable/c/f4d0775c6e2f1340ca0725f0337de149aaa989ca https://git.kernel.org/stable/c/73ae349534ebc377328e7d21891e589626c6e82c https://git.kernel.org/stable/c/5b0af8e4c70e4b884bb94ff5f0cd49ecf •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41019 – fs/ntfs3: Validate ff offset
https://notcve.org/view.php?id=CVE-2024-41019
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate ff offset This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read. • https://git.kernel.org/stable/c/35652dfa8cc9a8a900ec0f1e0395781f94ffc5f0 https://git.kernel.org/stable/c/818a257428644b8873e79c44404d8fb6598d4440 https://git.kernel.org/stable/c/6ae7265a7b816879fd0203e83b5030d3720bbb7a https://git.kernel.org/stable/c/82c94e6a7bd116724738aa67eba6f5fedf3a3319 https://git.kernel.org/stable/c/617cf144c206f98978ec730b17159344fd147cb4 https://git.kernel.org/stable/c/50c47879650b4c97836a0086632b3a2e300b0f06 •