Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix kernel crash when hard resetting the GPU<br /> <br /> The GPU hard reset sequence calls pm_runtime_force_suspend() and<br /> pm_runtime_force_resume(), which according to their documentation should<br /> only be used during system-wide PM transitions to sleep states.<br /> <br /> The main issue though is that depending on some internal runtime PM<br /> state as seen by pm_runtime_force_suspend() (whether the usage count is<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: qcom: msm: mark certain pins as invalid for interrupts<br /> <br /> On some platforms, the UFS-reset pin has no interrupt logic in TLMM but<br /> is nevertheless registered as a GPIO in the kernel. This enables the<br /> user-space to trigger a BUG() in the pinctrl-msm driver by running, for<br /> example: `gpiomon -c 0 113` on RB2.<br /> <br /> The exact culprit is requesting pins whose intr_detection_width setting<br /> is not 1 or 2 for interrupts. This hits a BUG() in<br /> msm_gpio_irq_set_type(). Potentially crashing the kernel due to an<br /> invalid request from user-space is not optimal, so let&amp;#39;s go through the<br /> pins and mark those that would fail the check as invalid for the irq chip<br /> as we should not even register them as available irqs.<br /> <br /> This function can be extended if we determine that there are more<br /> corner-cases like this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Increment job count before swapping tail spsc queue<br /> <br /> A small race exists between spsc_queue_push and the run-job worker, in<br /> which spsc_queue_push may return not-first while the run-job worker has<br /> already idled due to the job count being zero. If this race occurs, job<br /> scheduling stops, leading to hangs while waiting on the job’s DMA<br /> fences.<br /> <br /> Seal this race by incrementing the job count before appending to the<br /> SPSC queue.<br /> <br /> This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in<br /> an SVM test case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()<br /> <br /> There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For<br /> example, the following is possible:<br /> <br /> T0 T1<br /> zd_mac_tx_to_dev()<br /> /* len == skb_queue_len(q) */<br /> while (len &gt; ZD_MAC_MAX_ACK_WAITERS) {<br /> <br /> filter_ack()<br /> spin_lock_irqsave(&amp;q-&gt;lock, flags);<br /> /* position == skb_queue_len(q) */<br /> for (i=1; itype == NL80211_IFTYPE_AP)<br /> skb = __skb_dequeue(q);<br /> spin_unlock_irqrestore(&amp;q-&gt;lock, flags);<br /> <br /> skb_dequeue() -&gt; NULL<br /> <br /> Since there is a small gap between checking skb queue length and skb being<br /> unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.<br /> Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.<br /> <br /> In order to avoid potential NULL pointer dereference due to situations like<br /> above, check if skb is not NULL before passing it to zd_mac_tx_status().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: prevent A-MSDU attacks in mesh networks<br /> <br /> This patch is a mitigation to prevent the A-MSDU spoofing vulnerability<br /> for mesh networks. The initial update to the IEEE 802.11 standard, in<br /> response to the FragAttacks, missed this case (CVE-2025-27558). It can<br /> be considered a variant of CVE-2020-24588 but for mesh networks.<br /> <br /> This patch tries to detect if a standard MSDU was turned into an A-MSDU<br /> by an adversary. This is done by parsing a received A-MSDU as a standard<br /> MSDU, calculating the length of the Mesh Control header, and seeing if<br /> the 6 bytes after this header equal the start of an rfc1042 header. If<br /> equal, this is a strong indication of an ongoing attack attempt.<br /> <br /> This defense was tested with mac80211_hwsim against a mesh network that<br /> uses an empty Mesh Address Extension field, i.e., when four addresses<br /> are used, and when using a 12-byte Mesh Address Extension field, i.e.,<br /> when six addresses are used. Functionality of normal MSDUs and A-MSDUs<br /> was also tested, and confirmed working, when using both an empty and<br /> 12-byte Mesh Address Extension field.<br /> <br /> It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh<br /> networks keep being detected and prevented.<br /> <br /> Note that the vulnerability being patched, and the defense being<br /> implemented, was also discussed in the following paper and in the<br /> following IEEE 802.11 presentation:<br /> <br /> https://papers.mathyvanhoef.com/wisec2025.pdf<br /> https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kasan: remove kasan_find_vm_area() to prevent possible deadlock<br /> <br /> find_vm_area() couldn&amp;#39;t be called in atomic_context. If find_vm_area() is<br /> called to reports vm area information, kasan can trigger deadlock like:<br /> <br /> CPU0 CPU1<br /> vmalloc();<br /> alloc_vmap_area();<br /> spin_lock(&amp;vn-&gt;busy.lock)<br /> spin_lock_bh(&amp;some_lock);<br /> <br /> <br /> spin_lock(&amp;some_lock);<br /> <br /> kasan_report();<br /> print_report();<br /> print_address_description();<br /> kasan_find_vm_area();<br /> find_vm_area();<br /> spin_lock(&amp;vn-&gt;busy.lock) // deadlock!<br /> <br /> To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pf: Clear all LMTT pages on alloc<br /> <br /> Our LMEM buffer objects are not cleared by default on alloc<br /> and during VF provisioning we only setup LMTT PTEs for the<br /> actually provisioned LMEM range. But beyond that valid range<br /> we might leave some stale data that could either point to some<br /> other VFs allocations or even to the PF pages.<br /> <br /> Explicitly clear all new LMTT page to avoid the risk that a<br /> malicious VF would try to exploit that gap.<br /> <br /> While around add asserts to catch any undesired PTE overwrites<br /> and low-level debug traces to track LMTT PT life-cycle.<br /> <br /> (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()<br /> <br /> alloc_tag_top_users() attempts to lock alloc_tag_cttype-&gt;mod_lock even<br /> when the alloc_tag_cttype is not allocated because:<br /> <br /> 1) alloc tagging is disabled because mem profiling is disabled<br /> (!alloc_tag_cttype)<br /> 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)<br /> 3) alloc tagging is enabled, but failed initialization<br /> (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))<br /> <br /> In all cases, alloc_tag_cttype is not allocated, and therefore<br /> alloc_tag_top_users() should not attempt to acquire the semaphore.<br /> <br /> This leads to a crash on memory allocation failure by attempting to<br /> acquire a non-existent semaphore:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]<br /> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY<br /> Tainted: [D]=DIE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:down_read_trylock+0xaa/0x3b0<br /> Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff<br /> RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016<br /> RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000<br /> RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070<br /> RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1<br /> R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37<br /> R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000<br /> FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> codetag_trylock_module_list+0xd/0x20<br /> alloc_tag_top_users+0x369/0x4b0<br /> __show_mem+0x1cd/0x6e0<br /> warn_alloc+0x2b1/0x390<br /> __alloc_frozen_pages_noprof+0x12b9/0x21a0<br /> alloc_pages_mpol+0x135/0x3e0<br /> alloc_slab_page+0x82/0xe0<br /> new_slab+0x212/0x240<br /> ___slab_alloc+0x82a/0xe00<br /> <br /> <br /> As David Wang points out, this issue became easier to trigger after commit<br /> 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init").<br /> <br /> Before the commit, the issue occurred only when it failed to allocate and<br /> initialize alloc_tag_cttype or if a memory allocation fails before<br /> alloc_tag_init() is called. After the commit, it can be easily triggered<br /> when memory profiling is compiled but disabled at boot.<br /> <br /> To properly determine whether alloc_tag_init() has been called and its<br /> data structures initialized, verify that alloc_tag_cttype is a valid<br /> pointer before acquiring the semaphore. If the variable is NULL or an<br /> error value, it has not been properly initialized. In such a case, just<br /> skip and do not attempt to acquire the semaphore.<br /> <br /> [harry.yoo@oracle.com: v3]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix oops due to non-existence of prealloc backlog struct<br /> <br /> If an AF_RXRPC service socket is opened and bound, but calls are<br /> preallocated, then rxrpc_alloc_incoming_call() will oops because the<br /> rxrpc_backlog struct doesn&amp;#39;t get allocated until the first preallocation is<br /> made.<br /> <br /> Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no<br /> backlog struct. This will cause the incoming call to be aborted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix pp destruction warnings<br /> <br /> With multiple page pools and in some other cases we can have allocated<br /> niovs on page pool destruction. Remove a misplaced warning checking that<br /> all niovs are returned to zcrx on io_pp_zc_destroy(). It was reported<br /> before but apparently got lost.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: discard erroneous disassoc frames on STA interface<br /> <br /> When operating in concurrent STA/AP mode with host MLME enabled,<br /> the firmware incorrectly sends disassociation frames to the STA<br /> interface when clients disconnect from the AP interface.<br /> This causes kernel warnings as the STA interface processes<br /> disconnect events that don&amp;#39;t apply to it:<br /> <br /> [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211]<br /> [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us<br /> [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT<br /> [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)<br /> [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]<br /> [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211]<br /> [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211]<br /> [ 1303.370221] sp : ffff800083053be0<br /> [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae<br /> [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008<br /> [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006<br /> [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048<br /> [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000<br /> [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300<br /> [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002<br /> [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186<br /> [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de<br /> [ 1303.446221] Call trace:<br /> [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P)<br /> [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211]<br /> [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex]<br /> [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex]<br /> [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex]<br /> [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex]<br /> [ 1303.483734] process_one_work+0x14c/0x28c<br /> [ 1303.487845] worker_thread+0x2cc/0x3d4<br /> [ 1303.491680] kthread+0x12c/0x208<br /> [ 1303.495014] ret_from_fork+0x10/0x20<br /> <br /> Add validation in the STA receive path to verify that disassoc/deauth<br /> frames originate from the connected AP. Frames that fail this check<br /> are discarded early, preventing them from reaching the MLME layer and<br /> triggering WARN_ON().<br /> <br /> This filtering logic is similar with that used in the<br /> ieee80211_rx_mgmt_disassoc() function in mac80211, which drops<br /> disassoc frames that don&amp;#39;t match the current BSSID<br /> (!ether_addr_equal(mgmt-&gt;bssid, sdata-&gt;vif.cfg.ap_addr)), ensuring<br /> only relevant frames are processed.<br /> <br /> Tested on:<br /> - 8997 with FW 16.68.1.p197

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Allow CPU to reschedule while setting per-page memory attributes<br /> <br /> When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),<br /> the host can experience CPU soft lockups when running an operation in<br /> kvm_vm_set_mem_attributes() to set memory attributes on the whole<br /> range of guest memory.<br /> <br /> watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]<br /> CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)<br /> Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024<br /> RIP: 0010:xas_create+0x78/0x1f0<br /> Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87<br /> RSP: 0018:ffffad890a34b940 EFLAGS: 00000286<br /> RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000<br /> RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868<br /> R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868<br /> FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> xas_store+0x58/0x630<br /> __xa_store+0xa5/0x130<br /> xa_store+0x2c/0x50<br /> kvm_vm_set_mem_attributes+0x343/0x710 [kvm]<br /> kvm_vm_ioctl+0x796/0xab0 [kvm]<br /> __x64_sys_ioctl+0xa3/0xd0<br /> do_syscall_64+0x8c/0x7a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f5578d031bb<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb<br /> RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b<br /> RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000<br /> R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120<br /> R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0<br /> <br /> While looping through the range of memory setting the attributes,<br /> call cond_resched() to give the scheduler a chance to run a higher<br /> priority task on the runqueue if necessary and avoid staying in<br /> kernel mode long enough to trigger the lockup.