CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47713 – wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
https://notcve.org/view.php?id=CVE-2024-47713
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled. • https://git.kernel.org/stable/c/5061b0c2b9066de426fbc63f1278d2210e789412 https://git.kernel.org/stable/c/07eb0bd7b0a8abed9d45e0f567c9af1dc83e5268 https://git.kernel.org/stable/c/04f75f5bae33349283d6886901d9acd2f110c024 https://git.kernel.org/stable/c/f232916fab67ca1c3425926df4a866e59ff26908 https://git.kernel.org/stable/c/acb53a716e492a02479345157c43f21edc8bc64b https://git.kernel.org/stable/c/db5ca4b42ccfa42d2af7b335ff12578e57775c02 https://git.kernel.org/stable/c/058c9026ad79dc98572442fd4c7e9a36aba6f596 https://git.kernel.org/stable/c/eab272972cffff9cd973b8e4055a8e81c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47704 – drm/amd/display: Check link_res->hpo_dp_link_enc before using it
https://notcve.org/view.php?id=CVE-2024-47704
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. • https://git.kernel.org/stable/c/be2ca7a2c1561390d28bf2f92654d819659ba510 https://git.kernel.org/stable/c/530e29452b955c30cf2102fa4d07420dc6e0c953 https://git.kernel.org/stable/c/0508a4e95ac1aefd851ceb97ea050d8abb93262c https://git.kernel.org/stable/c/0beca868cde8742240cd0038141c30482d2b7eb8 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47699 – nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
https://notcve.org/view.php?id=CVE-2024-47699
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on. • https://git.kernel.org/stable/c/17c76b0104e4a6513983777e1a17e0297a12b0c4 https://git.kernel.org/stable/c/2b78e9df10fb7f4e9d3d7a18417dd72fbbc1dfd0 https://git.kernel.org/stable/c/1d94dbdfbb64cc48d10dec65cc3c4fbf2497b343 https://git.kernel.org/stable/c/24bf40740a3da6b4056721da34997ae6938f3da1 https://git.kernel.org/stable/c/73d23ecf234b7a6d47fb883f2dabe10e3230b31d https://git.kernel.org/stable/c/f68523e0f26faade18833fbef577a4295d8e2c94 https://git.kernel.org/stable/c/21839b6fbc3c41b3e374ecbdb0cabbbb2c53cf34 https://git.kernel.org/stable/c/db73500d3f0e558eb642aae1d4782e772 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47683 – drm/amd/display: Skip Recompute DSC Params if no Stream on Link
https://notcve.org/view.php?id=CVE-2024-47683
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? • https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9 https://git.kernel.org/stable/c/7c887efda1201110211fed8921a92a713e0b6bcd https://git.kernel.org/stable/c/718d83f66fb07b2cab89a1fc984613a00e3db18f https://git.kernel.org/stable/c/a53841b074cc196c3caaa37e1f15d6bc90943b97 https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad https://git.kernel.org/stable/c/6f9c39e8169384d2a5ca9bf323a0c1b81b3d0f3a https://git.kernel.org/stable/c/d45c64d933586d409d3f1e0ecaca4da494b1d9c6 https://git.kernel.org/stable/c/8151a6c13111b465dbabe07c19f572f7c •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47679 – vfs: fix race between evice_inodes() and find_inode()&iput()
https://notcve.org/view.php?id=CVE-2024-47679
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. • https://git.kernel.org/stable/c/63997e98a3be68d7cec806d22bf9b02b2e1daabb https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5 https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b81207 •