CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47718 – wifi: rtw88: always wait for both firmware loading attempts
https://notcve.org/view.php?id=CVE-2024-47718
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN. • https://git.kernel.org/stable/c/c8e5695eae9959fc5774c0f490f2450be8bad3de https://git.kernel.org/stable/c/a0c1e2da652cf70825739bc12d49ea15805690bf https://git.kernel.org/stable/c/ceaab3fb64d6a5426a3db8f87f3e5757964f2532 https://git.kernel.org/stable/c/7887ad11995a4142671cc49146db536f923c8568 https://git.kernel.org/stable/c/1b8178a2ae272256ea0dc4f940320a81003535e2 https://git.kernel.org/stable/c/9432185540bafd42b7bfac6e6ef2f0a0fb4be447 https://git.kernel.org/stable/c/e9a78d9417e167410d6fb83c4e908b077ad8ba6d https://git.kernel.org/stable/c/0e735a4c6137262bcefe45bb52fde7b1f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/eab272972cffff9cd973b8e4055a8e81c64f7e6a https://git.kernel.org/stable/c/ad4b7068b101fbbb4a9ca4b99b25eb051a9482ec https://git.kernel.org/stable/c/9d301de12da6e1bb069a9835c38359b8e •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-47712 – wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param
https://notcve.org/view.php?id=CVE-2024-47712
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed. • https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38 https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2 https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2 https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2 https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c9 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47710 – sock_map: Add a cond_resched() in sock_hash_free()
https://notcve.org/view.php?id=CVE-2024-47710
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed. • https://git.kernel.org/stable/c/75e68e5bf2c7fa9d3e874099139df03d5952a3e1 https://git.kernel.org/stable/c/5bed77b0a2a0e6b6bc0ae8e851cafb38ef0374df https://git.kernel.org/stable/c/6fc372656a1ebed8c1ebe0011881058c02eeddc0 https://git.kernel.org/stable/c/1a11a1a53255ddab8a903cdae01b9d3eb2c1a47b https://git.kernel.org/stable/c/984648aac87a6a1c8fd61663bec3f7b61eafad5e https://git.kernel.org/stable/c/04f62c012e0e4683e572b30baf6004ca0a3f6772 https://git.kernel.org/stable/c/80bd490ac0a3b662a489e17d8eedeb1e905a3d40 https://git.kernel.org/stable/c/ae8c1b3e7353ad240b829eabac7ba2584 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47709 – can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().
https://notcve.org/view.php?id=CVE-2024-47709
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK> • https://git.kernel.org/stable/c/aec92dbebdbec7567d9f56d7c9296a572b8fd849 https://git.kernel.org/stable/c/10bfacbd5e8d821011d857bee73310457c9c989a https://git.kernel.org/stable/c/3b39dc2901aa7a679a5ca981a3de9f8d5658afe8 https://git.kernel.org/stable/c/4377b79323df62eb5d310354f19b4d130ff58d50 https://git.kernel.org/stable/c/abb0a615569ec008e8a93d9f3ab2d5b418ea94d4 https://git.kernel.org/stable/c/76fe372ccb81b0c89b6cd2fec26e2f38c958be85 https://git.kernel.org/stable/c/5c680022c4e28ba18ea500f3e29f0428271afa92 https://git.kernel.org/stable/c/33ed4ba73caae39f34ab874ba79138bad •