CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49938 – wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit
https://notcve.org/view.php?id=CVE-2024-49938
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it. • https://git.kernel.org/stable/c/e6b9bf32e0695e4f374674002de0527d2a6768eb https://git.kernel.org/stable/c/d1f2fbc6a769081503f6ffedbb5cd1ac497f0e77 https://git.kernel.org/stable/c/b02eb7c86ff2ef1411c3095ec8a52b13f68db04f https://git.kernel.org/stable/c/012ae530afa0785102360de452745d33c99a321b https://git.kernel.org/stable/c/6a875220670475d9247e576c15dc29823100a4e4 https://git.kernel.org/stable/c/e37e348835032d6940ec89308cc8996ded691d2d https://git.kernel.org/stable/c/2c230210ec0ae6ed08306ac70dc21c24b817bb95 https://git.kernel.org/stable/c/a9f4e28e8adaf0715bd4e01462af0a52e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49937 – wifi: cfg80211: Set correct chandef when starting CAC
https://notcve.org/view.php?id=CVE-2024-49937
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? • https://git.kernel.org/stable/c/95f32191e50b75e0f75fae1bb925cdf51d8df0a3 https://git.kernel.org/stable/c/04053e55dd50741cf6c59b9bbaa4238218c05c70 https://git.kernel.org/stable/c/f4dbfda159e43d49b43003cc3c2914751939035f https://git.kernel.org/stable/c/c628026563f4ea9e0413dd4b69429e4a1db240b1 https://git.kernel.org/stable/c/20361712880396e44ce80aaeec2d93d182035651 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49936 – net/xen-netback: prevent UAF in xenvif_flush_hash()
https://notcve.org/view.php?id=CVE-2024-49936
In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe. • https://git.kernel.org/stable/c/a7f0073fcd12ed7de185ef2c0af9d0fa1ddef22c https://git.kernel.org/stable/c/a0465723b8581cad27164c9073fd780904cd22d4 https://git.kernel.org/stable/c/efcff6ce7467f01f0753609f420333f3f2ceceda https://git.kernel.org/stable/c/143edf098b80669d05245b2f2367dd156a83a2c5 https://git.kernel.org/stable/c/d408889d4b54f5501e4becc4dbbb9065143fbf4e https://git.kernel.org/stable/c/54d8639af5568fc41c0e274fc3ec9cf86c59fcbb https://git.kernel.org/stable/c/0fa5e94a1811d68fbffa0725efe6d4ca62c03d12 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49935 – ACPI: PAD: fix crash in exit_round_robin()
https://notcve.org/view.php?id=CVE-2024-49935
In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/. • https://git.kernel.org/stable/c/92e5661b7d0727ab912b76625a88b33fdb9b609a https://git.kernel.org/stable/c/68a599da16ebad442ce295d8d2d5c488e3992822 https://git.kernel.org/stable/c/68a8e45743d6a120f863fb14b72dc59616597019 https://git.kernel.org/stable/c/03593dbb0b272ef7b0358b099841e65735422aca https://git.kernel.org/stable/c/27c045f868f0e5052c6b532868a65e0cd250c8fc https://git.kernel.org/stable/c/0a2ed70a549e61c5181bad5db418d223b68ae932 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49934 – fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name
https://notcve.org/view.php?id=CVE-2024-49934
In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? • https://git.kernel.org/stable/c/f92b8829c6e75632de4e2b9f70e7a7e6c5c2ba98 https://git.kernel.org/stable/c/ef921bc72328b577cb45772ff7921cba4773b74a https://git.kernel.org/stable/c/7f7b850689ac06a62befe26e1fd1806799e7f152 •