Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap<br /> <br /> The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)-&gt;dev to<br /> calculate the needed headroom:<br /> <br /> err = skb_cow_head(skb,<br /> len + LL_RESERVED_SPACE(skb_dst(skb)-&gt;dev));<br /> <br /> But skb-&gt;_skb_refdst may not be initialized when the skb is set up by<br /> bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function<br /> in this scenario will trigger null pointer dereference, causing a kernel<br /> crash as Yinhao reported:<br /> <br /> [ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 105.186382] #PF: supervisor read access in kernel mode<br /> [ 105.186388] #PF: error_code(0x0000) - not-present page<br /> [ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0<br /> [ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1<br /> [ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520<br /> [ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0<br /> [ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246<br /> [ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00<br /> [ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500<br /> [ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000<br /> [ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98<br /> [ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002<br /> [ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000<br /> [ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0<br /> [ 105.186499] PKRU: 55555554<br /> [ 105.186502] Call Trace:<br /> [ 105.186507] <br /> [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40<br /> [ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49<br /> [ 105.186536] ? kvm_clock_get_cycles+0x18/0x30<br /> [ 105.186547] ? ktime_get+0x3c/0xa0<br /> [ 105.186554] bpf_test_run+0x195/0x320<br /> [ 105.186563] ? bpf_test_run+0x10f/0x320<br /> [ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0<br /> [ 105.186590] __sys_bpf+0x69c/0xa40<br /> [ 105.186603] __x64_sys_bpf+0x1e/0x30<br /> [ 105.186611] do_syscall_64+0x59/0x110<br /> [ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0<br /> [ 105.186649] RIP: 0033:0x7f166a97455d<br /> <br /> Temporarily add the setting of skb-&gt;_skb_refdst before bpf_test_run to resolve the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet<br /> <br /> The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and<br /> scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware.<br /> But it is never killed in rtl_pci_deinit(). When the rtlwifi card<br /> probe fails or is being detached, the ieee80211_hw is deallocated.<br /> However, irq_prepare_bcn_tasklet may still be running or pending,<br /> leading to use-after-free when the freed ieee80211_hw is accessed<br /> in _rtl_pci_prepare_bcn_tasklet().<br /> <br /> Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to<br /> ensure that irq_prepare_bcn_tasklet is properly terminated before<br /> the ieee80211_hw is released.<br /> <br /> The issue was identified through static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix memory leaks in beacon template setup<br /> <br /> The functions ath11k_mac_setup_bcn_tmpl_ema() and<br /> ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates<br /> but fail to free it when parameter setup returns an error.<br /> <br /> Since beacon templates must be released during normal execution, they<br /> must also be released in the error handling paths to prevent memory<br /> leaks.<br /> <br /> Fix this by using unified exit paths with proper cleanup in the respective<br /> error paths.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/amd/ibs: Avoid calling perf_allow_kernel() from the IBS NMI handler<br /> <br /> Calling perf_allow_kernel() from the NMI context is unsafe and could be<br /> fatal. Capture the permission at event-initialization time by storing it<br /> in event-&gt;hw.flags, and have the NMI handler rely on that cached flag<br /> instead of making the call directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ap: use generic driver_override infrastructure<br /> <br /> When the AP masks are updated via apmask_store() or aqmask_store(),<br /> ap_bus_revise_bindings() is called after ap_attr_mutex has been<br /> released.<br /> <br /> This calls __ap_revise_reserved(), which accesses the driver_override<br /> field without holding any lock, racing against a concurrent<br /> driver_override_store() that may free the old string, resulting in a<br /> potential UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure, which<br /> protects all accesses with an internal spinlock.<br /> <br /> Note that unlike most other buses, the AP bus does not check<br /> driver_override in its match() callback; the override is checked in<br /> ap_device_probe() and __ap_revise_reserved() instead.<br /> <br /> Also note that we do not enable the driver_override feature of struct<br /> bus_type, as AP - in contrast to most other buses - passes "" to<br /> sysfs_emit() when the driver_override pointer is NULL. Thus, printing<br /> "\n" instead of "(null)\n".<br /> <br /> Additionally, AP has a custom counter that is modified in the<br /> corresponding custom driver_override_store().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync<br /> <br /> roc_abort_sync() can deadlock with roc_work(). roc_work() holds<br /> dev-&gt;mt76.mutex, while cancel_work_sync() waits for roc_work()<br /> to finish. If the caller already owns the same mutex, both<br /> sides block and no progress is possible.<br /> <br /> This deadlock can occur during station removal when<br /> mt76_sta_state() -&gt; mt76_sta_remove() -&gt;<br /> mt7925_mac_sta_remove_link() -&gt; mt7925_mac_link_sta_remove() -&gt;<br /> mt7925_roc_abort_sync() invokes cancel_work_sync() while<br /> roc_work() is still running and holding dev-&gt;mt76.mutex.<br /> <br /> This avoids the mutex deadlock and preserves exactly-once<br /> work ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()<br /> <br /> mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to<br /> be freed eventually by mt76_mcu_skb_send_msg(). However, currently if<br /> an intermediate function fails before sending, the allocated skb is<br /> leaked.<br /> <br /> Specifically, mt76_connac_mcu_sta_wed_update() and<br /> mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory<br /> leak in the error path.<br /> <br /> Fix this by explicitly freeing the skb in these error paths.<br /> Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on<br /> mt7996_mcu_sta_key_tlv error") made a similar change.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync<br /> <br /> roc_abort_sync() can deadlock with roc_work(). roc_work() holds<br /> dev-&gt;mt76.mutex, while cancel_work_sync() waits for roc_work()<br /> to finish. If the caller already owns the same mutex, both<br /> sides block and no progress is possible.<br /> <br /> This deadlock can occur during station removal when<br /> mt76_sta_state() -&gt; mt76_sta_remove() -&gt; mt7921_mac_sta_remove() -&gt;<br /> mt7921_roc_abort_sync() invokes cancel_work_sync() while<br /> roc_work() is still running and holding dev-&gt;mt76.mutex.<br /> <br /> This avoids the mutex deadlock and preserves exactly-once<br /> work ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: fix deadlock in remain-on-channel<br /> <br /> mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel()<br /> while already holding dev-&gt;mutex. Since mt76_set_channel() also acquires<br /> dev-&gt;mutex, this results in a deadlock.<br /> <br /> Use __mt76_set_channel() instead of mt76_set_channel().<br /> Add cancel_delayed_work_sync() for mac_work before acquiring the mutex<br /> in mt76_remain_on_channel() to prevent a secondary deadlock with the<br /> mac_work workqueue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI<br /> <br /> This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG<br /> to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong<br /> name results in the code getting compiled out. Meaning the CFI failures<br /> for btf_dtor_kfunc_t would still trigger.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work()<br /> <br /> When the mt7915 pci chip is detaching, the mt7915_crash_data is<br /> released in mt7915_coredump_unregister(). However, the work item<br /> dump_work may still be running or pending, leading to UAF bugs<br /> when the already freed crash_data is dereferenced again in<br /> mt7915_mac_dump_work().<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (removal path) | CPU 1 (workqueue)<br /> mt7915_pci_remove() | mt7915_sys_recovery_set()<br /> mt7915_unregister_device() | mt7915_reset()<br /> mt7915_coredump_unregister() | queue_work()<br /> vfree(dev-&gt;coredump.crash_data) | mt7915_mac_dump_work()<br /> | crash_data-&gt; // UAF<br /> <br /> Fix this by ensuring dump_work is properly canceled before<br /> the crash_data is deallocated. Add cancel_work_sync() in<br /> mt7915_unregister_device() to synchronize with any pending<br /> or executing dump work.