CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45007 – char: xillybus: Don't destroy workqueue from work item running on it
https://notcve.org/view.php?id=CVE-2024-45007
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. • https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9 https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3 https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157 https://git.kernel.org/stable/c/aa1a19724fa2c31e97a9be48baedd4692b265157 https://git.kernel.org/stable/c/ccbde4b128ef9c73d14d0d7817d68ef795f6d131 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45006 – xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
https://notcve.org/view.php?id=CVE-2024-45006
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated. • https://git.kernel.org/stable/c/651aaf36a7d7b36a58980e70133f9437d4f6d312 https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6 https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59 https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1 https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e65 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-45003 – vfs: Don't evict inode under the inode lru traversing context
https://notcve.org/view.php?id=CVE-2024-45003
In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. • https://git.kernel.org/stable/c/e50e5129f384ae282adebfb561189cdb19b81cee https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a4 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45002 – rtla/osnoise: Prevent NULL dereference in error handling
https://notcve.org/view.php?id=CVE-2024-45002
In the Linux kernel, the following vulnerability has been resolved: rtla/osnoise: Prevent NULL dereference in error handling If the "tool->data" allocation fails then there is no need to call osnoise_free_top() and, in fact, doing so will lead to a NULL dereference. • https://git.kernel.org/stable/c/1eceb2fc2ca549a170d7ee7cd1fde2daeda646ac https://git.kernel.org/stable/c/fc575212c6b75d538e1a0a74f4c7e2ac73bc46ac https://git.kernel.org/stable/c/753f1745146e03abd17eec8eee95faffc96d743d https://git.kernel.org/stable/c/abdb9ddaaab476e62805e36cce7b4ef8413ffd01 https://git.kernel.org/stable/c/90574d2a675947858b47008df8d07f75ea50d0d0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45000 – fs/netfs/fscache_cookie: add missing "n_accesses" check
https://notcve.org/view.php?id=CVE-2024-45000
In the Linux kernel, the following vulnerability has been resolved: fs/netfs/fscache_cookie: add missing "n_accesses" check This fixes a NULL pointer dereference bug due to a data race which looks like this: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? • https://git.kernel.org/stable/c/12bb21a29c19aae50cfad4e2bb5c943108f34a7d https://git.kernel.org/stable/c/b8a50877f68efdcc0be3fcc5116e00c31b90e45b https://git.kernel.org/stable/c/dfaa39b05a6cf34a16c525a2759ee6ab26b5fef6 https://git.kernel.org/stable/c/0a4d41fa14b2a0efd40e350cfe8ec6a4c998ac1d https://git.kernel.org/stable/c/f71aa06398aabc2e3eaac25acdf3d62e0094ba70 •