Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix irq-disabled in local_bh_enable()<br /> <br /> The rxrpc_assess_MTU_size() function calls down into the IP layer to find<br /> out the MTU size for a route. When accepting an incoming call, this is<br /> called from rxrpc_new_incoming_call() which holds interrupts disabled<br /> across the code that calls down to it. Unfortunately, the IP layer uses<br /> local_bh_enable() which, config dependent, throws a warning if IRQs are<br /> enabled:<br /> <br /> WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0<br /> ...<br /> RIP: 0010:__local_bh_enable_ip+0x43/0xd0<br /> ...<br /> Call Trace:<br /> <br /> rt_cache_route+0x7e/0xa0<br /> rt_set_nexthop.isra.0+0x3b3/0x3f0<br /> __mkroute_output+0x43a/0x460<br /> ip_route_output_key_hash+0xf7/0x140<br /> ip_route_output_flow+0x1b/0x90<br /> rxrpc_assess_MTU_size.isra.0+0x2a0/0x590<br /> rxrpc_new_incoming_peer+0x46/0x120<br /> rxrpc_alloc_incoming_call+0x1b1/0x400<br /> rxrpc_new_incoming_call+0x1da/0x5e0<br /> rxrpc_input_packet+0x827/0x900<br /> rxrpc_io_thread+0x403/0xb60<br /> kthread+0x2f7/0x310<br /> ret_from_fork+0x2a/0x230<br /> ret_from_fork_asm+0x1a/0x30<br /> ...<br /> hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50<br /> hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70<br /> softirqs last enabled at (0): copy_process+0xc61/0x2730<br /> softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90<br /> <br /> Fix this by moving the call to rxrpc_assess_MTU_size() out of<br /> rxrpc_init_peer() and further up the stack where it can be done without<br /> interrupts disabled.<br /> <br /> It shouldn&amp;#39;t be a problem for rxrpc_new_incoming_call() to do it after the<br /> locks are dropped as pmtud is going to be performed by the I/O thread - and<br /> we&amp;#39;re in the I/O thread at this point.

Uncontrolled Resource Consumption vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java - BC-FJA 2.1.0 bc-fips (API modules) allows Excessive Allocation. This vulnerability is associated with program files org.Bouncycastle.Crypto.Fips.NativeLoader.<br /> <br /> This issue affects Bouncy Castle for Java - BC-FJA 2.1.0: from BC-FJA 2.1.0 through 2.1.0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Don&amp;#39;t call mmput from MMU notifier callback<br /> <br /> If the process is exiting, the mmput inside mmu notifier callback from<br /> compactd or fork or numa balancing could release the last reference<br /> of mm struct to call exit_mmap and free_pgtable, this triggers deadlock<br /> with below backtrace.<br /> <br /> The deadlock will leak kfd process as mmu notifier release is not called<br /> and cause VRAM leaking.<br /> <br /> The fix is to take mm reference mmget_non_zero when adding prange to the<br /> deferred list to pair with mmput in deferred list work.<br /> <br /> If prange split and add into pchild list, the pchild work_item.mm is not<br /> used, so remove the mm parameter from svm_range_unmap_split and<br /> svm_range_add_child.<br /> <br /> The backtrace of hung task:<br /> <br /> INFO: task python:348105 blocked for more than 64512 seconds.<br /> Call Trace:<br /> __schedule+0x1c3/0x550<br /> schedule+0x46/0xb0<br /> rwsem_down_write_slowpath+0x24b/0x4c0<br /> unlink_anon_vmas+0xb1/0x1c0<br /> free_pgtables+0xa9/0x130<br /> exit_mmap+0xbc/0x1a0<br /> mmput+0x5a/0x140<br /> svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]<br /> mn_itree_invalidate+0x72/0xc0<br /> __mmu_notifier_invalidate_range_start+0x48/0x60<br /> try_to_unmap_one+0x10fa/0x1400<br /> rmap_walk_anon+0x196/0x460<br /> try_to_unmap+0xbb/0x210<br /> migrate_page_unmap+0x54d/0x7e0<br /> migrate_pages_batch+0x1c3/0xae0<br /> migrate_pages_sync+0x98/0x240<br /> migrate_pages+0x25c/0x520<br /> compact_zone+0x29d/0x590<br /> compact_zone_order+0xb6/0xf0<br /> try_to_compact_pages+0xbe/0x220<br /> __alloc_pages_direct_compact+0x96/0x1a0<br /> __alloc_pages_slowpath+0x410/0x930<br /> __alloc_pages_nodemask+0x3a9/0x3e0<br /> do_huge_pmd_anonymous_page+0xd7/0x3e0<br /> __handle_mm_fault+0x5e3/0x5f0<br /> handle_mm_fault+0xf7/0x2e0<br /> hmm_vma_fault.isra.0+0x4d/0xa0<br /> walk_pmd_range.isra.0+0xa8/0x310<br /> walk_pud_range+0x167/0x240<br /> walk_pgd_range+0x55/0x100<br /> __walk_page_range+0x87/0x90<br /> walk_page_range+0xf6/0x160<br /> hmm_range_fault+0x4f/0x90<br /> amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]<br /> amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]<br /> init_user_pages+0xb1/0x2a0 [amdgpu]<br /> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]<br /> kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]<br /> kfd_ioctl+0x29d/0x500 [amdgpu]<br /> <br /> (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Disable INVLPGB on Zen2<br /> <br /> AMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an issue<br /> that causes system oopses and panics when performing TLB flush using<br /> INVLPGB.<br /> <br /> However, the problem is that that machine has misconfigured CPUID and<br /> should not report the INVLPGB bit in the first place. So zap the<br /> kernel&amp;#39;s representation of the flag so that nothing gets confused.<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon: fix divide by zero in damon_get_intervals_score()<br /> <br /> The current implementation allows having zero size regions with no special<br /> reasons, but damon_get_intervals_score() gets crashed by divide by zero<br /> when the region size is zero.<br /> <br /> [ 29.403950] Oops: divide error: 0000 [#1] SMP NOPTI<br /> <br /> This patch fixes the bug, but does not disallow zero size regions to keep<br /> the backward compatibility since disallowing zero size regions might be a<br /> breaking change for some users.<br /> <br /> In addition, the same crash can happen when intervals_goal.access_bp is<br /> zero so this should be fixed in stable trees as well.

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)