Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: pidff: Fix condition effect bit clearing<br /> <br /> As reported by MPDarkGuy on discord, NULL pointer dereferences were<br /> happening because not all the conditional effects bits were cleared.<br /> <br /> Properly clear all conditional effect bits from ffbit

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: Fix race of nvdimm_bus object when creating nvdimm objects<br /> <br /> Found issue during running of cxl-translate.sh unit test. Adding a 3s<br /> sleep right before the test seems to make the issue reproduce fairly<br /> consistently. The cxl_translate module has dependency on cxl_acpi and<br /> causes orphaned nvdimm objects to reprobe after cxl_acpi is removed.<br /> The nvdimm_bus object is registered by the cxl_nvb object when<br /> cxl_acpi_probe() is called. With the nvdimm_bus object missing,<br /> __nd_device_register() will trigger NULL pointer dereference when<br /> accessing the dev-&gt;parent that points to &amp;nvdimm_bus-&gt;dev.<br /> <br /> [ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c<br /> [ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025<br /> [ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core]<br /> [ 192.899459] RIP: 0010:kobject_get+0xc/0x90<br /> [ 192.924871] Call Trace:<br /> [ 192.925959] <br /> [ 192.926976] ? pm_runtime_init+0xb9/0xe0<br /> [ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm]<br /> [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm]<br /> [ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem]<br /> [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core]<br /> [ 192.943349] really_probe+0xde/0x380<br /> <br /> This patch also relies on the previous change where<br /> devm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead<br /> of drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.<br /> <br /> 1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the<br /> driver is probed synchronously when add_device() is called.<br /> 2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the<br /> cxl_nvb driver is attached during cxl_acpi_probe().<br /> 3. Take the cxl_root uport_dev lock and the cxl_nvb-&gt;dev lock in<br /> devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.<br /> 4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe()<br /> will exit with -EBUSY.<br /> <br /> The removal of cxl_nvdimm devices should prevent any orphaned devices<br /> from probing once the nvdimm_bus is gone.<br /> <br /> [ dj: Fixed 0-day reported kdoc issue. ]<br /> [ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fred: Correct speculative safety in fred_extint()<br /> <br /> array_index_nospec() is no use if the result gets spilled to the stack, as<br /> it makes the believed safe-under-speculation value subject to memory<br /> predictions.<br /> <br /> For all practical purposes, this means array_index_nospec() must be used in<br /> the expression that accesses the array.<br /> <br /> As the code currently stands, it&amp;#39;s the wrong side of irqentry_enter(), and<br /> &amp;#39;index&amp;#39; is put into %ebp across the function call.<br /> <br /> Remove the index variable and reposition array_index_nospec(), so it&amp;#39;s<br /> calculated immediately before the array access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: usb: f81604: correctly anchor the urb in the read bulk callback<br /> <br /> When submitting an urb, that is using the anchor pattern, it needs to be<br /> anchored before submitting it otherwise it could be leaked if<br /> usb_kill_anchored_urbs() is called. This logic is correctly done<br /> elsewhere in the driver, except in the read bulk callback so do that<br /> here also.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: io: Extract user memory type in ioremap_prot()<br /> <br /> The only caller of ioremap_prot() outside of the generic ioremap()<br /> implementation is generic_access_phys(), which passes a &amp;#39;pgprot_t&amp;#39; value<br /> determined from the user mapping of the target &amp;#39;pfn&amp;#39; being accessed by<br /> the kernel. On arm64, the &amp;#39;pgprot_t&amp;#39; contains all of the non-address<br /> bits from the pte, including the permission controls, and so we end up<br /> returning a new user mapping from ioremap_prot() which faults when<br /> accessed from the kernel on systems with PAN:<br /> <br /> | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000<br /> | ...<br /> | Call trace:<br /> | __memcpy_fromio+0x80/0xf8<br /> | generic_access_phys+0x20c/0x2b8<br /> | __access_remote_vm+0x46c/0x5b8<br /> | access_remote_vm+0x18/0x30<br /> | environ_read+0x238/0x3e8<br /> | vfs_read+0xe4/0x2b0<br /> | ksys_read+0xcc/0x178<br /> | __arm64_sys_read+0x4c/0x68<br /> <br /> Extract only the memory type from the user &amp;#39;pgprot_t&amp;#39; in ioremap_prot()<br /> and assert that we&amp;#39;re being passed a user mapping, to protect us against<br /> any changes in future that may require additional handling. To avoid<br /> falsely flagging users of ioremap(), provide our own ioremap() macro<br /> which simply wraps __ioremap_prot().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: gcs: Do not set PTE_SHARED on GCS mappings if FEAT_LPA2 is enabled<br /> <br /> When FEAT_LPA2 is enabled, bits 8-9 of the PTE replace the<br /> shareability attribute with bits 50-51 of the output address. The<br /> _PAGE_GCS{,_RO} definitions include the PTE_SHARED bits as 0b11 (this<br /> matches the other _PAGE_* definitions) but using this macro directly<br /> leads to the following panic when enabling GCS on a system/model with<br /> LPA2:<br /> <br /> Unable to handle kernel paging request at virtual address fffff1ffc32d8008<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> swapper pgtable: 4k pages, 52-bit VAs, pgdp=0000000060f4d000<br /> [fffff1ffc32d8008] pgd=100000006184b003, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> CPU: 0 UID: 0 PID: 513 Comm: gcs_write_fault Tainted: G M 7.0.0-rc1 #1 PREEMPT<br /> Tainted: [M]=MACHINE_CHECK<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 2025.02-8+deb13u1 11/08/2025<br /> pstate: 03402005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : zap_huge_pmd+0x168/0x468<br /> lr : zap_huge_pmd+0x2c/0x468<br /> sp : ffff800080beb660<br /> x29: ffff800080beb660 x28: fff00000c2058180 x27: ffff800080beb898<br /> x26: fff00000c2058180 x25: ffff800080beb820 x24: 00c800010b600f41<br /> x23: ffffc1ffc30af1a8 x22: fff00000c2058180 x21: 0000ffff8dc00000<br /> x20: fff00000c2bc6370 x19: ffff800080beb898 x18: ffff800080bebb60<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000007<br /> x14: 000000000000000a x13: 0000aaaacbbbffff x12: 0000000000000000<br /> x11: 0000ffff8ddfffff x10: 00000000000001fe x9 : 0000ffff8ddfffff<br /> x8 : 0000ffff8de00000 x7 : 0000ffff8da00000 x6 : fff00000c2bc6370<br /> x5 : 0000ffff8da00000 x4 : 000000010b600000 x3 : ffffc1ffc0000000<br /> x2 : fff00000c2058180 x1 : fffff1ffc32d8000 x0 : 000000c00010b600<br /> Call trace:<br /> zap_huge_pmd+0x168/0x468 (P)<br /> unmap_page_range+0xd70/0x1560<br /> unmap_single_vma+0x48/0x80<br /> unmap_vmas+0x90/0x180<br /> unmap_region+0x88/0xe4<br /> vms_complete_munmap_vmas+0xf8/0x1e0<br /> do_vmi_align_munmap+0x158/0x180<br /> do_vmi_munmap+0xac/0x160<br /> __vm_munmap+0xb0/0x138<br /> vm_munmap+0x14/0x20<br /> gcs_free+0x70/0x80<br /> mm_release+0x1c/0xc8<br /> exit_mm_release+0x28/0x38<br /> do_exit+0x190/0x8ec<br /> do_group_exit+0x34/0x90<br /> get_signal+0x794/0x858<br /> arch_do_signal_or_restart+0x11c/0x3e0<br /> exit_to_user_mode_loop+0x10c/0x17c<br /> el0_da+0x8c/0x9c<br /> el0t_64_sync_handler+0xd0/0xf0<br /> el0t_64_sync+0x198/0x19c<br /> Code: aa1603e2 d34cfc00 cb813001 8b011861 (f9400420)<br /> <br /> Similarly to how the kernel handles protection_map[], use a<br /> gcs_page_prot variable to store the protection bits and clear PTE_SHARED<br /> if LPA2 is enabled.<br /> <br /> Also remove the unused PAGE_GCS{,_RO} macros.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix use-after-free on error path<br /> <br /> In the error path of sev_tsm_init_locked(), the code dereferences &amp;#39;t&amp;#39;<br /> after it has been freed with kfree(). The pr_err() statement attempts<br /> to access t-&gt;tio_en and t-&gt;tio_init_done after the memory has been<br /> released.<br /> <br /> Move the pr_err() call before kfree(t) to access the fields while the<br /> memory is still valid.<br /> <br /> This issue reported by Smatch static analyser

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: produce a warning when calculated tailroom is negative<br /> <br /> Many ethernet drivers report xdp Rx queue frag size as being the same as<br /> DMA write size. However, the only user of this field, namely<br /> bpf_xdp_frags_increase_tail(), clearly expects a truesize.<br /> <br /> Such difference leads to unspecific memory corruption issues under certain<br /> circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when<br /> running xskxceiver&amp;#39;s XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses<br /> all DMA-writable space in 2 buffers. This would be fine, if only<br /> rxq-&gt;frag_size was properly set to 4K, but value of 3K results in a<br /> negative tailroom, because there is a non-zero page offset.<br /> <br /> We are supposed to return -EINVAL and be done with it in such case, but due<br /> to tailroom being stored as an unsigned int, it is reported to be somewhere<br /> near UINT_MAX, resulting in a tail being grown, even if the requested<br /> offset is too much (it is around 2K in the abovementioned test). This later<br /> leads to all kinds of unspecific calltraces.<br /> <br /> [ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6<br /> [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4<br /> [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000]<br /> [ 7340.339230] in xskxceiver[42b5,400000+69000]<br /> [ 7340.340300] likely on CPU 6 (core 0, socket 6)<br /> [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe<br /> [ 7340.340888] likely on CPU 3 (core 0, socket 3)<br /> [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7<br /> [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI<br /> [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)<br /> [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> [ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80<br /> [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89<br /> [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202<br /> [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010<br /> [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff<br /> [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0<br /> [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0<br /> [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500<br /> [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000<br /> [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0<br /> [ 7340.421237] PKRU: 55555554<br /> [ 7340.421623] Call Trace:<br /> [ 7340.421987] <br /> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0<br /> [ 7340.422855] swap_pte_batch+0xa7/0x290<br /> [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270<br /> [ 7340.424102] zap_pte_range+0x281/0x580<br /> [ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240<br /> [ 7340.425177] unmap_page_range+0x24d/0x420<br /> [ 7340.425714] unmap_vmas+0xa1/0x180<br /> [ 7340.426185] exit_mmap+0xe1/0x3b0<br /> [ 7340.426644] __mmput+0x41/0x150<br /> [ 7340.427098] exit_mm+0xb1/0x110<br /> [ 7340.427539] do_exit+0x1b2/0x460<br /> [ 7340.427992] do_group_exit+0x2d/0xc0<br /> [ 7340.428477] get_signal+0x79d/0x7e0<br /> [ 7340.428957] arch_do_signal_or_restart+0x34/0x100<br /> [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0<br /> [ 7340.430159] do_syscall_64+0x188/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix race in cpumap on PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, the per-CPU xdp_bulk_queue (bq) can be accessed<br /> concurrently by multiple preemptible tasks on the same CPU.<br /> <br /> The original code assumes bq_enqueue() and __cpu_map_flush() run<br /> atomically with respect to each other on the same CPU, relying on<br /> local_bh_disable() to prevent preemption. However, on PREEMPT_RT,<br /> local_bh_disable() only calls migrate_disable() (when<br /> PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable<br /> preemption, which allows CFS scheduling to preempt a task during<br /> bq_flush_to_queue(), enabling another task on the same CPU to enter<br /> bq_enqueue() and operate on the same per-CPU bq concurrently.<br /> <br /> This leads to several races:<br /> <br /> 1. Double __list_del_clearprev(): after bq-&gt;count is reset in<br /> bq_flush_to_queue(), a preempting task can call bq_enqueue() -&gt;<br /> bq_flush_to_queue() on the same bq when bq-&gt;count reaches<br /> CPU_MAP_BULK_SIZE. Both tasks then call __list_del_clearprev()<br /> on the same bq-&gt;flush_node, the second call dereferences the<br /> prev pointer that was already set to NULL by the first.<br /> <br /> 2. bq-&gt;count and bq-&gt;q[] races: concurrent bq_enqueue() can corrupt<br /> the packet queue while bq_flush_to_queue() is processing it.<br /> <br /> The race between task A (__cpu_map_flush -&gt; bq_flush_to_queue) and<br /> task B (bq_enqueue -&gt; bq_flush_to_queue) on the same CPU:<br /> <br /> Task A (xdp_do_flush) Task B (cpu_map_enqueue)<br /> ---------------------- ------------------------<br /> bq_flush_to_queue(bq)<br /> spin_lock(&amp;q-&gt;producer_lock)<br /> /* flush bq-&gt;q[] to ptr_ring */<br /> bq-&gt;count = 0<br /> spin_unlock(&amp;q-&gt;producer_lock)<br /> bq_enqueue(rcpu, xdpf)<br /> bq-&gt;q[bq-&gt;count++] = xdpf<br /> /* ... more enqueues until full ... */<br /> bq_flush_to_queue(bq)<br /> spin_lock(&amp;q-&gt;producer_lock)<br /> /* flush to ptr_ring */<br /> spin_unlock(&amp;q-&gt;producer_lock)<br /> __list_del_clearprev(flush_node)<br /> /* sets flush_node.prev = NULL */<br /> <br /> __list_del_clearprev(flush_node)<br /> flush_node.prev-&gt;next = ...<br /> /* prev is NULL -&gt; kernel oops */<br /> <br /> Fix this by adding a local_lock_t to xdp_bulk_queue and acquiring it<br /> in bq_enqueue() and __cpu_map_flush(). These paths already run under<br /> local_bh_disable(), so use local_lock_nested_bh() which on non-RT is<br /> a pure annotation with no overhead, and on PREEMPT_RT provides a<br /> per-CPU sleeping lock that serializes access to the bq.<br /> <br /> To reproduce, insert an mdelay(100) between bq-&gt;count = 0 and<br /> __list_del_clearprev() in bq_flush_to_queue(), then run reproducer<br /> provided by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix crash when destroying a suspended hardware context<br /> <br /> If userspace issues an ioctl to destroy a hardware context that has<br /> already been automatically suspended, the driver may crash because the<br /> mailbox channel pointer is NULL for the suspended context.<br /> <br /> Fix this by checking the mailbox channel pointer in aie2_destroy_context()<br /> before accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()<br /> <br /> There is a use-after-free error in cfg80211_shutdown_all_interfaces found<br /> by syzkaller:<br /> <br /> BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220<br /> Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326<br /> CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: events cfg80211_rfkill_block_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x116/0x1f0<br /> print_report+0xcd/0x630<br /> kasan_report+0xe0/0x110<br /> cfg80211_shutdown_all_interfaces+0x213/0x220<br /> cfg80211_rfkill_block_work+0x1e/0x30<br /> process_one_work+0x9cf/0x1b70<br /> worker_thread+0x6c8/0xf10<br /> kthread+0x3c5/0x780<br /> ret_from_fork+0x56d/0x700<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> The problem arises due to the rfkill_block work is not cancelled when wiphy<br /> is being unregistered. In order to fix the issue cancel the corresponding<br /> work in wiphy_unregister().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()<br /> <br /> struct irdma_create_ah_resp { // 8 bytes, no padding<br /> __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah-&gt;sc_ah.ah_info.ah_idx)<br /> __u8 rsvd[4]; // offset 4 - NEVER SET