Vulnerabilities

The Linux kernel's XE GPU driver (drm/xe, used for Intel Xe graphics) rounds the flat CCS compression-storage base up to 128 KiB and hands everything below that limit to the VRAM allocator, publishing the tail of a page that actually belongs to the GPU's compression hardware as free memory. The compression hardware overwrites that tail with metadata without needing a page-table entry, buffer object, or GPU submission, and does so before userspace even starts. On an Intel Battlemage G21 with 16 GiB VRAM, a Mesa VM's level-3 page table repeatedly landed on that page at cold boot, losing the mapping for the compositor's batch-buffer heap and causing gdm to restart in a loop, i.e. a black screen on an otherwise working machine. The flaw is rated 7.8 (high) with local attack vector and high confidentiality, integrity and availability impact, so the resulting memory corruption is exploitable in principle by a local attacker. No public proof-of-concept or known exploitation exists and the issue is not in CISA KEV; affected users are those running kernels with the XE driver on affected Intel Xe2/Battlemage hardware until they install a kernel with the one-line round_down() fix.

Do: Update to a Linux kernel build that includes the drm/xe fix (round_down() instead of round_up() in get_flat_ccs_offset()); no fixed version number is given in the data, so check your distribution for a kernel containing this patch. If you experience a black screen with gdm restarting in a loop at cold boot on a Battlemage GPU, restarting the display manager reallocates the page tables and temporarily clears the symptom. Confirm whether CONFIG_DRM_XE is enabled in your kernel and whether your system uses an Intel Xe2/Battlemage GPU; the equality-based debug assertion that should have caught this only compiles in with CONFIG_DRM_XE_DEBUG.

The Linux kernel's page allocator free path (free_pages_nolock()) performs an unsafe spin_trylock() when running in NMI context on uniprocessor (non-SMP) kernel builds; a prior fix (commit 620b46ed6ae17) addressed the allocation side but missed the free side. The flaw is triggered when BPF programs that use these page-allocation/freeing features in NMI context — most plausibly BPF tracing programs — run on a non-SMP kernel. A local attacker who can load such BPF programs could crash the kernel, and the reporter assesses it is probably exploitable for local privilege escalation. Only non-SMP/UP kernel builds are affected, and the patch author states the bugs were found by code review, have not been reproduced, and that no real-world user is suspected to be affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Apply the upstream mm/page_alloc fix from the 'fixes for free_pages_nolock() on RT/UP' patch series (patch 1 of 2) once it lands in mainline and stable trees for your kernel version. Operators of non-SMP/UP kernels (embedded, IoT, minimal single-vCPU systems) should audit whether BPF programs using NMI-context tracing/allocation features are loaded and restrict unprivileged BPF if so. SMP kernel builds are not affected.

The Linux kernel's USB gadget functionfs (ffs) driver stores a raw pointer to the submitting task's mm_struct for asynchronous I/O without holding a reference while requests are pending. A local user who queues async read requests through functionfs and then exits before completion handling finishes can trigger a use-after-free on the freed mm_struct. An attacker with low local privileges could potentially corrupt kernel memory to escalate privileges, read or write sensitive memory, or crash the system, consistent with the CVSS 3.1 score of 7.8 (AV:L/PR:L with high confidentiality, integrity, and availability impact). Any system running an affected kernel with the functionfs gadget in use is affected — a configuration common on Android devices (which use f_fs for ADB) and embedded/USB-peripheral deployments, but rare on typical servers and desktops. There is no public proof-of-concept, the issue is not in the CISA KEV catalog, and no in-the-wild exploitation is known.

Do: Upgrade to a kernel release that includes the upstream fix, which takes an mmgrab() reference when queuing the ffs read request and drops it with mmdrop() on completion; since exact fixed version numbers are not provided in the data, track the stable branch containing this ffs patch. If the system does not need USB gadget/functionfs functionality, disable or unload the f_fs gadget module to eliminate the attack surface. Restrict local shell access on devices that do use functionfs (e.g., ADB-enabled Android builds) until patched.

A use-after-free exists in the Linux kernel's USB gadget FunctionFS driver (f_fs), in the ffs_epfile_write_iter() and ffs_epfile_read_iter() functions. When an AIO (asynchronous I/O) operation fails with an error other than -EIOCBQUEUED, the io_data structure is freed while the kiocb cancellation handler is still armed and still points to that freed memory; a concurrent sys_io_cancel() call in that window dereferences the freed pointer. A local attacker with low privileges and access to a FunctionFS endpoint can trigger this race, gaining kernel memory corruption with potential for privilege escalation, since the CVSS impact is rated high for confidentiality, integrity, and availability (7.8, local vector). Affected systems are primarily Linux kernels with the f_fs gadget driver enabled, a configuration most common on Android devices (adbd uses FunctionFS) and embedded Linux boards acting as USB devices. No public proof-of-concept or exploitation in the wild is known, and the issue is not listed in CISA's KEV catalog.

Do: Apply the upstream kernel patch (or a stable/vendor backport that un-arms the kiocb cancellation in the f_fs AIO error path); for Android, install vendor security updates that include this kernel fix. As mitigation, restrict read/write access to /dev/usb-ffs/* endpoint nodes to trusted processes and avoid running untrusted local code on affected devices. Check whether your kernel configuration enables CONFIG_USB_FUNCTIONFS and whether any components use AIO (io_submit/io_cancel) on FunctionFS endpoints.

The zram compressed-swap driver in the Linux kernel stores its per-slot lock as a bit inside a 64-bit word that doubles as two 32-bit fields (entry flags and last-access time). On 64-bit big-endian systems the lock bit lands in the access-time half of the word, so when access-time tracking (ZRAM_TRACK_ENTRY_ACTIME) is enabled, a normal access-time write from mark_slot_accessed() or slot_free() erases a held lock bit, letting another CPU acquire the same slot lock concurrently; conversely, an access-time value that happens to set that bit makes the slot appear locked forever. A local, low-privilege attacker could exploit the resulting race to corrupt zram slot state, and the CVSS vector indicates high potential impact on confidentiality, integrity, and availability, i.e., possible local privilege escalation or a persistent denial of service. Only systems running zram on 64-bit big-endian architectures (e.g., s390x, big-endian POWER, sparc64) with access-time tracking enabled are affected; little-endian platforms such as x86_64, ARM64, and Android are not. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not in CISA's KEV catalog.

Do: Apply the upstream kernel commit that shifts the slot-lock bit into the flags half of the word on big-endian 64-bit, or install your vendor's backported kernel update once published (the source data names no fixed version, so track vendor advisories). As an interim mitigation on affected big-endian hosts, avoid zram or do not enable access-time tracking (ZRAM_TRACK_ENTRY_ACTIME/writeback tracking), which is what clobbers the lock bit. Prioritize patching multi-tenant s390x/POWER/sparc systems, since exploitation requires only local low privileges.

The Ceph filesystem client in the Linux kernel allocates message buffers with kvmalloc(), which can fall back to vmalloc() memory when fragmentation prevents a large contiguous allocation, but ceph_fname_to_usr() passed these raw MDS reply buffers to the fscrypt scatterlist crypto API, which only accepts linear-mapping addresses. When a readdir/metadata reply from the Ceph metadata server lands in a vmalloc() buffer on a CephFS mount with filename encryption enabled, the kernel hits an invalid address and oopses; the reporter's testing hit this on roughly 1 in 8,000 readdir messages, with crashes most likely on non-x86 architectures. An attacker who controls or can spoof the Ceph metadata server, or can intercept client-cluster traffic, can therefore trigger kernel crashes — a denial of service; despite the CNA's 9.8 network-vector score, the advisory describes oopses rather than demonstrated code execution or data theft. Only Linux systems using the kernel CephFS client with fs-encryption (encrypted filenames) are affected. No in-the-wild exploitation or public PoC is known, although the fix commit references a reproducer, and the fix routes vmalloc() addresses through a linear bounce buffer.

Do: Update Linux systems that mount CephFS with encryption to a kernel containing the 'ceph: properly decrypt filenames in vmalloc() buffers' commit (latest mainline/stable, or your vendor's backport once released). As an interim mitigation, disable filename encryption on CephFS mounts and restrict which hosts can reach or impersonate the Ceph monitors/MDS, since a malicious or on-path metadata server is required to trigger the flaw. Audit your fleet for CephFS mounts using fscrypt to confirm whether you are in the affected population.

CVE-2026-90041 is a use-after-free in the Linux kernel's HID 'sony' driver (drivers/hid/hid-sony.c) caused by incorrect cleanup when controller probing fails. When a Sony controller is connected, sony_input_configured() links its state into sony_device_list before the input device is registered; if input_register_device() then fails, sony_probe() frees the driver state (via devres) while the list node is still linked, leaving a dangling entry in the shared device list. A subsequent controller connection that traverses the list touches freed memory, which could be leveraged for memory corruption or a crash by an attacker with local/adjacent access — such as plugging in or pairing over USB/Bluetooth a crafted or malfunctioning Sony-class HID device — consistent with the CVSS 8.8 (high, adjacent network, C:H/I:H/A:H) score. Any Linux system whose kernel includes the sony HID driver is affected, though the advisory does not specify vulnerable or fixed version ranges. No public proof-of-concept and no known in-the-wild exploitation; the flaw was found by 0sec using automated source analysis.

Do: Update to a kernel that includes the sony driver probe-failure cleanup patch as soon as your distribution ships it (mainline/stable backport; no fixed version number is given in the advisory). Until then, avoid attaching Sony DualShock-class controllers from untrusted sources to patched-pending systems, or blacklist the hid_sony module where Sony controllers are not needed (verify with 'lsmod | grep hid_sony').

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [ ] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [ ] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [ ] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [ ] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: NFSD: Guard admin state-revocation walks with NFSD_NET_UP Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.

CVE-2026-90038 is a use-after-free in the Linux kernel's NFS server (NFSD): nfsd4_revoke_export_states() drops the shared client_lock across revoke_one_stid() and a subsequent read of clp->cl_minorversion, and the stateid reference it holds does not pin the client, so a concurrent client teardown can free the client while it is still being dereferenced. The flaw is reached when an administrator removes an NFS export — exportfs -u drives the path via the NFSD_CMD_UNLOCK_EXPORT netlink command — and that revocation races with a client expiry. Successful triggering yields a kernel use-after-free that can crash the server (denial of service) and, as is typical for kernel UAF bugs, may be exploitable for privilege escalation; the assigned CVSS 3.1 score is 9.8 critical (AV:N/AC:L/PR:N), although practical triggering requires the export-revocation path to race client expiry. Any Linux system acting as an NFS server with the export-state revocation code is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Apply the upstream patch 'NFSD: Prevent client use-after-free during export state revocation' and update to a kernel that includes the fix. As an interim mitigation, avoid removing exports (exportfs -u / NFSD_CMD_UNLOCK_EXPORT) while NFSv4 clients are active or expiring, and schedule export changes during maintenance windows. Check whether your running kernel contains the nfsd4_revoke_export_states()/UNLOCK_EXPORT code to determine if the issue is relevant to your systems.

A use-after-free flaw in the Linux kernel's NFS server daemon (NFSD) occurs when an open owner left on the close_lru list after its final CLOSE keeps its last closed stateid holding only a raw, unpinned pointer to its nfs4_client. When the NFSD laundromat thread reaps a timed-out entry it drops the client lock and calls nfs4_put_stid(), which dereferences the client through cl_lock; a concurrent force_expire_client() can free the client in that window, so the server reads freed kernel memory, and __destroy_client() hits the same race by walking cl_openowners without holding cl_lock. An attacker acting as an NFS client that opens/closes files and triggers or coincides with client expiry could corrupt server kernel memory, most plausibly crashing the server (denial of service) and potentially more, per the critical CVSS score. Any Linux system running the in-kernel NFSv4 server (NFSD) — enterprise file servers, virtualization storage hosts, and Linux-based NAS appliances — is potentially affected. No public proof-of-concept or in-the-wild exploitation is currently known.

Do: Upgrade to a kernel that includes the NFSD fix (pinning the client via cl_rpc_users before dropping client_lock) — since no fixed version is given in the advisory, follow your distribution's kernel security tracker for the backported update. Until patched, restrict NFS access (TCP/UDP 2049 and related ports) to trusted client networks with firewall rules and tight export ACLs, and avoid unnecessary forced client-expiry operations on production servers. Monitor servers for NFSD crashes, hung NFS clients, or kernel use-after-free/oops messages involving nfs4_put_stid or the laundromat thread.

CVE-2026-90036 is a use-after-free in the Linux kernel's NFS server (NFSD) state management: a 'bare' lock owner whose only remaining reference is a blocked lock on the blocked_locks LRU holds a raw pointer to its nfs4_client without keeping the client alive. When the per-net laundromat reaps such a blocked lock, freeing the lock owner can make nfs4_put_stateowner() dereference the client's cl_lock, and because the laundromat detaches the lock first, a concurrent force_expire_client() can free the client before that call, touching freed memory. Triggering it requires NFS clients performing blocked-lock (NLM) operations while client expiry runs concurrently, which an attacker able to mount exports could attempt remotely. A successful exploit corrupts kernel memory in the NFS state machinery, with potential for denial of service and, per the CVSS 9.8 score, high confidentiality/integrity/availability impact. Any Linux system acting as an NFS server is potentially affected; no public proof-of-concept or in-the-wild exploitation is currently known.

Do: Apply the upstream NFSD fix via your distribution's kernel update as soon as vendors ship it. In the meantime, restrict NFS access (TCP/UDP 2049) to trusted clients with firewall rules, avoid unauthenticated or broad exports, and check whether the NFS server service is enabled and whether any clients rely on blocked (NLM) locks. Not currently listed in CISA KEV and no public exploit is known.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)

In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.

A use-after-free flaw in the Linux kernel's usbtv driver, which handles USBTV007-class USB video capture dongles, can leave a freed driver structure referenced by an open ALSA PCM stream. If the USB device is disconnected while a PCM file is still open, the disconnect path drops the V4L2 device reference and frees struct usbtv, because usbtv_audio_free() uses snd_card_free_when_closed(); a later close of that PCM file then dereferences freed memory in snd_usbtv_pcm_close(). The fix takes a V4L2 device reference for the ALSA card and releases it from the card's private_free callback, keeping struct usbtv alive until ALSA has closed remaining files. A local attacker able to open the dongle's ALSA/V4L2 device nodes and trigger or race with a disconnect could crash the kernel or potentially achieve code execution with high confidentiality, integrity, and availability impact, consistent with the CVSS 7.8 local-attack vector. Only Linux systems with a kernel built with the usbtv driver and a supported capture dongle attached are affected, and no public proof-of-concept, known exploitation, or KEV listing exists.

Do: Update to a kernel that includes the commit 'media: usbtv: keep device alive while ALSA card exists' or apply your distribution's backported stable/kernel security update when released. Check whether you are exposed with 'lsmod | grep usbtv'; systems without a USBTV007-class dongle are not affected. As an interim mitigation, restrict access to the relevant /dev/snd and /dev/video device nodes to trusted local users and avoid unplugging the dongle while audio streams are open.

In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.

The Linux kernel's DWC3 USB controller driver issued EndTransfer commands with the forceRM bit set, as older Synopsys programming guides recommended; on DWC_usb31 v2.00a and v2.10a controllers this leaves an aborted transfer active after the EndTransfer command completes. A local attacker who can trigger an endpoint dequeue (the ep_dequeue path) followed by a new StartTransfer on the same endpoint can cause the controller to DMA into a buffer that has already been unmapped, producing an SMMU (IOMMU) fault. The practical result is a kernel crash/denial of service, and the 7.8 High CVSS score (C:H/I:H/A:H) reflects potential memory-safety impact from stale DMA writes. Any Linux system whose silicon uses Synopsys DWC_usb31 v2.00a or v2.10a with the DWC3 driver is affected, which includes many ARM SoCs in Android phones, development boards, and embedded/gadget-mode devices. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been reported.

Do: Update Linux systems using DWC3 to a kernel that includes the fix commit ('usb: dwc3: clear forceRM when issuing EndTransfer'); no fixed release number is provided in the data, so pull the latest stable or vendor kernel. Operators of ARM/embedded, OTG, or USB-gadget systems should verify whether their SoC integrates Synopsys DWC_usb31 v2.00a or v2.10a (check SoC documentation or controller revision registers) and limit local untrusted user access, since exploitation requires local code execution. No workarounds, public PoCs, or in-the-wild exploitation are currently known.

In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.

A use-after-free race condition exists in the Linux kernel's Qualcomm PMIC USB Type-C port controller driver (usb: typec: qcom-pmic-typec). When a Type-C port is stopped, the cc_debounce delayed work can still be re-queued by TCPM callbacks (set_cc and start_toggling) running in TCPM's worker thread, because port_stop() returns before tcpm_unregister_port() destroys that worker; the delayed work can then execute after devres has freed the pmic_typec_port memory. A local attacker who can trigger Type-C port bring-up/teardown, such as rapid plug/unplug cycles or unbinding the device, could cause kernel memory corruption, leading to a crash or potentially privilege escalation (CVSS 7.8, high C/I/A, local attack vector). Only Linux systems running on Qualcomm Snapdragon-class platforms with this driver enabled are affected. No public proof-of-concept or in-the-wild exploitation is known; the flaw was found by static analysis and is not listed in CISA KEV.

Do: Update to a kernel release that includes the upstream fix, which changes port_stop() to use disable_delayed_work_sync(); specific fixed version numbers were not listed in the advisory. Check whether your kernels enable CONFIG_TYPEC_QCOM_PMIC / qcom-pmic-typec and run on Qualcomm hardware, and prioritize patching multi-user systems where local users could trigger Type-C port re-registration. As an interim mitigation, restrict unprivileged local access and avoid unbinding or repeatedly re-registering the affected Type-C port.

CVE-2026-90026 is a use-after-free flaw in the Qualcomm PMIC USB Type-C driver (qcom-pmic) in the Linux kernel: the pdphy_stop() routine disables the PHY's IRQs but leaves a previously scheduled reset_work still pending. If the IRQ handler queues reset_work in the window just before disable_irq() is called, the work item can execute after the driver's remove() path has already freed its backing structure via the devm allocator, causing the work to operate on freed memory. A local attacker with low privileges (the CVSS vector is AV:L/PR:L) who can trigger driver stop/unbind races could gain kernel-level impact, with the CVSS indicating potential for high confidentiality, integrity, and availability impact (kernel memory corruption, crash, or possible local privilege escalation). Affected systems are Linux deployments on Qualcomm Snapdragon platforms where this driver is enabled, such as recent Android flagship handsets and Qualcomm-based ARM laptops. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known; the bug was found by an in-house static analysis tool.

Do: Apply the kernel update containing the fix commit that calls cancel_work_sync() after IRQs are disabled in pdphy_stop(), including the backport to your vendor's stable/maintained kernel branch (specific fixed version tags were not published in the available data). Device and OS vendors building kernels for Qualcomm Snapdragon platforms should verify the patch is included in their next release. Because exploitation requires local low-privileged code execution, avoid running untrusted local code/apps on affected devices until patched; no workarounds or in-the-wild exploitation are known.

The Linux kernel's USB Type-C UCSI DisplayPort altmode driver uses the GET_CURRENT_CAM response from the platform policy manager (typically the USB-C firmware on a laptop or dock) to index the connector's port altmode array, checking only that the value is not 0xff. If the PPM returns an invalid value greater than UCSI_MAX_ALTMODES, the driver performs an out-of-bounds array access that can crash the kernel and may expose kernel memory. Per the CVSS vector (AV:L, no privileges required), a local attacker who can induce such a response, e.g., through a malicious or buggy USB-C device, gains denial of service and potentially information disclosure. Affected systems are Linux machines running kernels with the UCSI DisplayPort altmode driver enabled, which is standard on USB-C-capable laptops and desktops in mainstream distributions. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists.

Do: Update to a Linux kernel that includes the upstream fix validating that the GET_CURRENT_CAM value is below UCSI_MAX_ALTMODES, and track your distribution's kernel errata since exact fixed version numbers are not provided in the data. Until patched, be cautious with untrusted USB-C docks and monitors, and consider unloading or blacklisting the ucsi DisplayPort altmode module on systems that do not need DisplayPort over USB-C. Because the attack vector is local, internet-exposed servers without local users face minimal risk.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.

The Linux kernel's f_midi2 USB gadget driver has a use-after-free in the configfs 'show' path for its string attributes: f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the string pointer before that lock is taken. A local attacker who can concurrently read and write a gadget string attribute (interface name, block name, or endpoint string) can hit a race in which the store path frees the old string under the lock while the show path is still dereferencing it outside the lock. Exploitation could yield kernel memory disclosure or corruption; the CVSS 7.8 score (local vector, high confidentiality/integrity/availability impact) indicates potential local privilege escalation. Only systems that actually instantiate the f_midi2 USB gadget function via configfs — typically embedded audio/music hardware and Linux devices emulating a USB MIDI 2.0 device — are exposed. No exploitation in the wild, public proof-of-concept, or KEV listing is known.

Do: Apply a kernel update containing the CVE-2026-90022 fix (or the vendor backport); the specific fixed release is not stated in the provided data, so track your distro's stable kernel advisories. Restrict configfs gadget attribute permissions to root and avoid untrusted local users on systems with f_midi2 gadget instances. Check whether you are exposed by looking for the f_midi2 module loaded or gadget instances configured under the kernel's usb_gadget configfs tree.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().

In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.

The rtw_get_wps_attr() function in the Linux kernel's staging rtl8723bs driver (Realtek RTL8723BS SDIO Wi-Fi) validates only that a WPS attribute's fixed 4-byte header fits inside the WPS information element, but copies attr_len bytes — a value read directly from the wire and never checked against the remaining IE length — via memcpy(). A crafted WPS IE in a beacon or probe response received during Wi-Fi scanning therefore causes both an out-of-bounds heap read and, at several call sites where the destination is a single-byte stack variable, a stack buffer overflow in the parsing thread. An attacker in radio range can trigger this without authentication or user interaction, potentially crashing the kernel, leaking memory, or gaining code execution in the kernel via stack corruption. Only Linux systems that use the staging rtl8723bs driver (i.e., devices with RTL8723BS Wi-Fi hardware) are affected. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been reported.

Do: Update the Linux kernel to a release or stable branch that includes the fix adding the missing attr_len bounds check in rtw_get_wps_attr(); check with your distro for patched kernel packages. If patching is not possible, blacklist or disable the r8723bs staging driver, or restrict affected devices to trusted wireless networks since exploitation requires an attacker within radio range. Only systems with RTL8723BS Wi-Fi hardware are impacted; other Realtek drivers and Wi-Fi chipsets are not affected by this bug.

CVE-2026-90017 is a missing length-validation flaw in rtw_action_frame_parse() in the Linux kernel's staging driver for Realtek RTL8723BS SDIO Wi-Fi adapters: the function reads frame_body[0] and frame_body[1] (bytes 25-26 of the frame) without ever checking the frame_len it was given, so an 802.11 management action frame shorter than 26 bytes (e.g., the 24-byte minimum a peer can send) causes a 1-2 byte out-of-bounds read. It is reachable through rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx(), which pass attacker/user-influenced frame buffers and lengths straight through, so a malicious peer within wireless range (adjacent-network access per the CVSS vector) can trigger it. An attacker gains limited information disclosure and, per the 7.1 (High) CVSS score, potentially a kernel crash, with availability impact rated high. Affected systems are any Linux machines using the mainline staging rtl8723bs driver, typically budget tablets, mini-PCs and TV sticks built around the RTL8723BS chip. No public proof-of-concept and no in-the-wild exploitation are known, and the flaw is not on CISA KEV.

Do: Update the kernel to a build that includes the staging rtl8723bs fix, which adds the missing frame_len check in rtw_action_frame_parse(), as soon as your distribution ships it. Until patched, check whether the driver is in use (lsmod for the rtl8723bs/r8723bs module or kernel CONFIG_RTL8723BS) and on unpatched systems near untrusted wireless peers, unload or blacklist the module or avoid monitor-interface/mgmt_tx frame injection. No public exploit is known, so exposure is concentrated on hobbyist and embedded Linux devices within radio range of a hostile peer.

A one-byte out-of-bounds read exists in rtw_restruct_wmm_ie() in the Linux kernel's staging rtl8723bs driver (Realtek RTL8723BS SDIO Wi-Fi): when the bounds-guarded WMM IE match check fails because the scan position is within 5 bytes of the buffer end, execution still falls through to i += (in_ie[i + 1] + 2), reading in_ie[i + 1] one byte past the buffer. An attacker within Wi-Fi range can trigger it using attacker-influenced IE data built from association/scan traffic, crafted so the scan reaches the last byte without finding a WMM IE. Per the CVSS vector (AV:A/AC:L/PR:N/UI:N, C:L/I:N/A:H), an attacker gains limited confidentiality impact (possible small information disclosure) and potentially high availability impact (kernel crash/denial of service), with no integrity impact. Affected users are those running Linux systems that use the in-kernel staging rtl8723bs driver; the advisory data does not specify exact vulnerable or fixed kernel version numbers. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is currently known.

Do: Update affected systems to a kernel that includes the new bounds check in rtw_restruct_wmm_ie() (watch distro kernel advisories for the backported fix, as the earlier commit a75281626fc8f was insufficient). As a mitigation, unload or blacklist the r8723bs module on Linux systems not using RTL8723BS Wi-Fi, and avoid associating with or scanning untrusted wireless networks in range of this driver until patched.

In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]

The Linux kernel tracing subsystem's show_event_filters and show_event_triggers files, which display all filters or triggers set within a trace array (trace instance), do not take a reference on the trace array they are reading. A local attacker can trigger a race by holding one of these files open (iterating its events) while the trace instance is deleted via 'rmdir', freeing the trace_array while its data is still being read, resulting in a use-after-free kernel crash and potentially local privilege escalation (CVSS C:H/I:H/A:H). Any Linux system running a kernel that includes these recently added tracing files is affected, provided a local user can access the tracefs interface. No public proof-of-concept is known and the issue is not listed in CISA's Known Exploited Vulnerabilities catalog.

Do: Update affected systems to a kernel release that includes the tracing fix adding the trace_array_get() reference in the open handlers of show_event_filters/show_event_triggers. As interim mitigation, restrict access to /sys/kernel/tracing (tracefs) to root or trusted groups so unprivileged local users cannot race file reads against instance 'rmdir' operations. Check whether tracefs is mounted and these files are present on your systems to determine applicability.

CVE-2026-90013 is a use-after-free flaw in the Linux kernel's ftrace tracing subsystem: the per-instance 'options' files under tracefs do not take a reference on the trace_array structure they describe. A local process that opens one of these files can race against another task deleting the corresponding tracing instance, freeing the options descriptor while it is still in use and causing a kernel use-after-free crash. The CVSS vector rates this high for confidentiality, integrity, and availability with only low local privileges required, meaning a kernel crash (denial of service) and potentially local privilege escalation typical of use-after-free bugs. Any Linux system where the tracefs/debugfs tracing files are reachable by untrusted local users is affected; the source data does not specify exact kernel version ranges. No in-the-wild exploitation, public proof-of-concept, or CISA KEV listing is known; the fix adds a trace_array_options_get() helper that takes a trace_array reference when the file is opened.

Do: Install a kernel update that includes the upstream fix 'tracing: Take trace_array reference when opening options file' as soon as your distribution ships it. Until then, restrict access to /sys/kernel/tracing and /sys/kernel/debug/tracing to root or trusted administrators, and audit for unprivileged processes opening tracefs options files or creating/removing tracing instances.

CVE-2026-90012 is an error-handling flaw in the Linux kernel's SPI (Serial Peripheral Interface) subsystem: when RX DMA mapping fails after TX mapping has succeeded, or TX mapping fails on a later transfer, __spi_map_msg() leaves stale mapping flags and stale/NULL cur_tx_dma_dev/cur_rx_dma_dev pointers, because those device pointers are only published after all transfers are mapped. The follow-up spi_unmap_msg() can then unmap the same TX mapping twice or call dma_unmap_sg_attrs() with a NULL or stale device — and since that function dereferences the device before checking the SG entry count, a NULL device triggers a kernel oops (crash). An attacker who can cause DMA mapping failures on an SPI controller with DMA gains at minimum denial of service, and the incorrect release of DMA mappings carries potential memory-safety implications consistent with the reported critical CVSS (9.8), although the network vector depends on driver-specific conditions. Affected are any systems running Linux kernels with SPI controllers that use DMA, a configuration typical of embedded and ARM-based devices. No public proof-of-concept exists, the flaw is not in CISA KEV, and no exploitation is currently known.

Do: Patch by pulling the upstream commit 'spi: Fix DMA mapping ownership on partial map failure' into your kernel or take the corresponding update from your kernel/board vendor's stable or LTS stream once published (no specific fixed version numbers are available in the source data), prioritizing ARM/embedded products whose kernels enable SPI controllers with DMA. No workaround is documented; if you cannot patch immediately, avoid workloads that stress SPI DMA under memory pressure and investigate any kernel oopses surfacing in dma_unmap_sg_attrs() during SPI transfers. Since no exploitation is known, systems not using SPI can patch at normal cadence.

The Linux kernel's iSCSI target implementation (LIO, drivers/target/iscsi) allocates the login request buffer at exactly MAX_KEY_VALUE_PAIRS (8192) bytes, and its length check uses '>' instead of '>=', so a login PDU payload of 8189-8192 bytes (plus padding) fills the entire buffer with no byte left for a NUL terminator. The buffer is subsequently parsed as a C string by functions such as strstr(), kstrdup() and strlen_semi() in the CHAP authentication path, and convert_null_to_semi() rewrites embedded NULs to semicolons, so parsing walks past the end of the object into adjacent slab memory (out-of-bounds read). An unauthenticated initiator can trigger it by sending a crafted login request to a portal configured for CHAP authentication; portals that do not require authentication rewrite AuthMethod to None and never enter the CHAP path. Per the CVSS score of 9.1, an attacker gains information disclosure (C:H) and denial of service (A:H), with no integrity impact. No public proof-of-concept or in-the-wild exploitation is known; the fix allocates one extra zeroed byte so the buffer is always terminated.

Do: Apply a kernel update containing this SCSI target (iscsi_target) fix as soon as it reaches your vendor/distro kernel; no fixed version number is given in the source data, so check your vendor's advisory for the backport. Until patched, restrict TCP port 3260 on iSCSI portals to trusted initiator networks with firewall/ACL rules, and note that portals without mandatory CHAP (AuthMethod None) are not reachable through the vulnerable code path. Check whether any Linux hosts run targetcli/LIO with CHAP configured and whether those portals are exposed beyond the storage network.

The Linux kernel's SCSI bsg driver overruns the user-supplied response buffer when completing io_uring passthrough requests: the completion path copied the reported sense length into the user's buffer without capping the copy to the user-declared max_response_len. A local user who can submit commands to a bsg device can trigger this by issuing a command that returns SCSI sense data longer than their response buffer, since after valid sense the midlayer sets sense_len to the real length, up to SCSI_SENSE_BUFFERSIZE. The overrun writes past the end of the caller's buffer, giving a local attacker potential denial of service, memory corruption, or disclosure per the CVSS 7.8 rating (C:H/I:H/A:H, local, low privileges). Any Linux system running a kernel with io_uring bsg passthrough support and SCSI devices present is affected, though exploitation requires access to the /dev/bsg device node, which distributions typically restrict to root or the disk group. No public proof-of-concept or in-the-wild exploitation is currently known, and the issue is not in CISA's KEV catalog.

Do: Update to a kernel build that includes the upstream fix 'scsi: bsg: Cap io_uring sense copy to max_response_len' as it lands in your distribution's security updates. Until patched, restrict write/open access to /dev/bsg/* device nodes to trusted root or disk-group users and audit udev rules for looser permissions; where supported, kernel.io_uring_disabled can be set to block unprivileged io_uring use as a stopgap. Check whether any local service accounts or containers can reach bsg device nodes on affected hosts.

CVE-2026-90009 is a time-of-check to time-of-use (TOCTOU) race in the Linux kernel's SCSI bsg driver's io_uring passthrough path, where scsi_bsg_uring_cmd() validates fields in the io_uring submission queue entry (SQE) that is shared with userspace via mmap and then re-reads them from that same mutable memory. A local attacker can change a field between the check and its use; the critical case is request_len, which can grow past sizeof(scmd->cmnd) after the bounds check and overflow the scmd->cmnd buffer during copy_from_user(), corrupting kernel memory. An attacker with low privileges and access to a bsg device node gains a kernel memory-corruption primitive that can lead to privilege escalation, information disclosure, or a system crash (CVSS 3.1 rates confidentiality, integrity, and availability impact as High). Any Linux system running a kernel that includes the bsg io_uring passthrough support is potentially affected, provided the SCSI bsg driver is present and its device nodes are accessible. No public proof-of-concept is known, the issue is not in the CISA KEV catalog, and no exploitation in the wild has been reported.

Do: Install a kernel update containing the upstream fix that READ_ONCE()-copies the checked SQE fields into locals before use (your distribution's patched kernel build). Until patched, restrict access to /dev/bsg/* device nodes to trusted/root users and consider restricting io_uring on multi-user systems (e.g., the kernel.io_uring_disabled sysctl where available). Check whether CONFIG_BLK_DEV_BSG is enabled and whether unprivileged local users can open /dev/bsg nodes to assess actual exposure.

The Linux kernel's megaraid_sas driver builds NVMe PRP lists for I/O commands in a fixed-size DMA pool buffer (cmd->sg_frame) without checking its bounds, so the list can overrun the frame when the request is large. Since the block layer raised its default maximum request size to 4 MiB (commit 9b8b84879d4a), transfers to NVMe drives whose firmware reports a large MDTS require more PRP entries than fit in the chain frame, running a page past its end. An attacker with local low-privileged access who can issue I/O to such a drive can crash the kernel with a page fault, or, if the adjacent page is mapped, silently corrupt another in-flight command's PRP list, leading to denial of service, data corruption, and potentially privilege escalation. Affected are Linux systems with MegaRAID SAS controllers managing NVMe drives on kernels carrying the raised block-layer default. No public proof-of-concept or in-the-wild exploitation is known, and the flaw is not in CISA's KEV catalog.

Do: Update to a kernel containing the megaraid_sas fix that caps max_hw_sectors to what the PRP chain frame can describe. As an interim mitigation, cap the request size for NVMe drives behind MegaRAID SAS controllers (e.g., write a value no larger than ~1280 KiB to /sys/block/<sdX>/queue/max_sectors_kb). Audit servers using megaraid_sas for NVMe passthrough/JBOD drives and check logs for page-fault traces in megasas_build_and_issue_cmd_fusion.

The Linux kernel's pm8001 driver (PMC/Microchip PM8001/PM80xx SAS/SATA HBA controllers) contains an error-handling flaw in pm8001_request_msix(): when request_irq() fails during MSI-X vector registration, the rollback loop frees vectors using the failing index i instead of the already-registered index j. This passes the wrong IRQ/dev_id pair to free_irq(), so earlier successfully registered interrupt handlers are left installed with mismatched vector entries. The bug is only triggered on systems where the pm8001 driver loads on PM8001/PM80xx hardware and the MSI-X request path fails mid-registration, e.g. due to interrupt allocation exhaustion. A local attacker with low privileges could potentially influence IRQ allocation to reach this path, and the leftover handlers can lead to crashes or undefined behavior; the CVSS 7.8 score reflects high confidentiality, integrity and availability impact. No public proof-of-concept exists, the issue is not listed in CISA's KEV, and no exploitation is known.

Do: Update the kernel to a version that includes the pm8001 rollback-index fix (watch stable-tree backports of the 'scsi: pm8001: Use rollback index when freeing MSI-X vectors' commit, since exact fixed version numbers are not provided in the data). Check whether the driver is in use with 'lsmod | grep pm8001' — systems without PM8001/PM80xx HBA hardware or with the module unloaded are not affected. There is no runtime workaround; standard hardening (restricting local unprivileged access on storage servers) reduces any chance of influencing the IRQ-failure path.

In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: handle region split failure in apply_min_nr_regions() damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko.

The Linux kernel futex subsystem contains a use-after-free race in the FUTEX_CMP_REQUEUE_PI path on PREEMPT_RT (real-time preemption) kernels: the futex_q used by futex_wait_requeue_pi() lives on the waiter's task stack, and an early wakeup (timeout or signal) can race with a PI requeue so that the requeue task calls rcuwait_wake_up() after the waiter has already returned from the syscall and the stack object is gone, producing a KASAN slab-out-of-bounds report in futex_requeue_pi_complete(). The race is triggered by local code using the FUTEX_CMP_REQUEUE_PI operation in a way that makes the waiter wake up while a requeue is in progress. A successful exploit corrupts kernel memory, and the CVSS 3.1 score of 7.8 (local vector, low privileges, high confidentiality/integrity/availability impact) is consistent with local privilege escalation or kernel crash. Only systems running Linux kernels built with PREEMPT_RT enabled are affected; standard (non-RT) kernel configurations are not implicated by this report. No public proof-of-concept is known, the flaw is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.

Do: Update affected real-time Linux kernels with the futex requeue PI fix via your distribution or vendor's backport (the patch skips the rcuwait_wake_up() call in the Q_REQUEUE_PI_LOCKED case), and check whether your kernel configuration enables PREEMPT_RT to determine if you are exposed. Until patched, limit local untrusted code execution on real-time systems, and watch distro/kernel.org advisories for the fixed package versions since the source data does not name them.

The Linux kernel's ftrace subsystem contains a use-after-free in the handling of per-instance set_ftrace_filter and set_ftrace_notrace files. When such a file is opened, the code dereferences an ftrace_ops pointer stored in the inode's private data to take a reference on the trace instance (trace_array); if an administrator removes the instance via rmdir during that window, the ftrace_ops may already have been freed, and touching it corrupts kernel memory and can crash the kernel. Triggering it requires local code execution and access to tracefs, plus a concurrent rmdir of a tracing instance while an instance filter file is opened — a narrow but scriptable race. On systems that grant low-privileged users access to tracefs, this is exploitable for denial of service (kernel crash) and, per the CVSS vector's high confidentiality/integrity/availability ratings, potentially for local privilege escalation. No public proof-of-concept is known and the flaw is not in the CISA KEV catalog, so exploitation has not been observed.

Do: Patch kernels with the ftrace fix from the upstream commit (available via backports in distribution kernel updates; check your vendor's errata for CVE-2026-90002). As a mitigation, restrict /sys/kernel/tracing (tracefs) to root or fully trusted groups, and avoid concurrently removing trace instances while instance filter files are open. Verify exposure by checking whether tracefs is mounted and which users or groups have read/write access to it.

CVE-2026-90001 is a race condition in the Linux kernel's HID BPF subsystem in which the device-destruction path (__hid_bpf_ops_destroy_device) and the BPF unregistration path (hid_bpf_unreg) can both release the same reference to a HID device, double-putting it and freeing the device while hid_destroy_device() is still using it, causing a use-after-free. It is triggered locally when a HID BPF program attached via the struct_ops mechanism is torn down concurrently with device destruction — for example, a BPF map delete or link release racing with the HID device's destroy traversal. A local attacker with low privileges (in practice, the ability to attach BPF programs, which normally requires CAP_BPF/CAP_SYS_ADMIN) can crash the kernel and, given the freed-memory window during teardown, potentially compromise confidentiality, integrity and availability as reflected in the 7.8 CVSS score. Only systems running kernels that include the HID BPF struct_ops destroy path and with HID BPF programs actively attached are affected. No public proof-of-concept is known, there are no reports of in-the-wild exploitation, and the issue is not in CISA KEV.

Do: Update the kernel to a version that includes the fix serializing the remove/NULL decision under hdev->bpf.prog_list_lock once it is merged in mainline and backported to stable branches for your kernel series. As an interim mitigation, do not load HID BPF struct_ops programs on multi-user or exposed systems and restrict CAP_BPF/CAP_SYS_ADMIN to trusted processes. Audit hosts with bpftool or similar to check whether any HID BPF struct_ops programs or links are currently attached.

The Linux kernel's hid-rmi driver (Synaptics RMI4 over HID) sizes its report buffers purely from the HID report descriptor the device declares, with no minimum bound, and then writes fixed offsets and device-controlled copy lengths into them, producing heap out-of-bounds writes, out-of-bounds reads past the allocation into adjacent slab objects, and a probe loop that never terminates when a device answers with zero-length replies. Triggering requires only a device bound to hid-rmi with undersized reports: even an honest device declaring an input report smaller than 23 bytes makes the fixed 21-byte F01 register read run out of bounds, while a malicious or compromised HID device (touchpad, dock, USB adapter) with lying descriptors fully controls the overflow lengths. An attacker gains kernel heap corruption (potential local privilege escalation), leakage of heap bytes to unprivileged userspace via the world-readable (mode 0444) sysfs product id attribute and to the device itself via the interrupt mask, or a denial of service by wedging the probe worker while it holds page_mutex. Affected are Linux systems where hid-rmi binds, chiefly machines with Synaptics RMI4-over-HID touchpads or touchscreens; the CVSSv3.1 score is 8.8 (AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H), reflecting an attacker with adjacent access to the connected HID device. No in-the-wild exploitation, public PoC, or CISA KEV listing is known; the fix rejects too-small reports at probe time (minimum 6 output / 3 input bytes), clamps the read and write copies, treats zero-length replies as errors, and falls rejected devices back to ordinary HID operation.

Do: Update to a kernel containing the upstream hid-rmi fix (minimum 6 output / 3 input report bytes at probe, clamped read/write copies, zero-length replies treated as errors); the fixed release numbers are not given in the source data, so track your distribution's kernel advisory or backport the commit. Until patched, avoid untrusted USB/HID peripherals and check kernel logs for hid-rmi binding to unexpected devices; on patched systems an undersized RMI device simply falls back to plain HID operation.

OpenMeter before v1.0.0-beta.228 fails to safely handle user-controlled JSONPath values in meter definitions backed by ClickHouse, resulting in SQL injection (CWE-89). A remote, unauthenticated attacker can submit crafted JSONPath expressions to the meters API, causing them to be incorporated into ClickHouse queries. Successful exploitation allows the attacker to read or modify metering event data and can potentially disrupt the service, leading to denial of service. All deployments of OpenMeter earlier than v1.0.0-beta.228 on any platform are affected, with self-hosted instances of this open-source usage-metering platform being the primary exposure. No public proof-of-concept is known, the issue is not listed in CISA's KEV, and there are no confirmed reports of exploitation so far.

Do: Upgrade OpenMeter to v1.0.0-beta.228 or later as soon as possible. If an immediate upgrade is not possible, restrict network access to the meters API (e.g., place it behind an authenticating reverse proxy or limit it to trusted networks). Afterwards, review ClickHouse logs and metering event data for signs of unauthorized access or modification.

The Linux kernel's HID Wacom driver parses Bluetooth reports from Intuos Pro (P2), Intuos S (P2) and third-generation Intuos (INTUOSHT3) tablets in wacom_intuos_pro2_bt_irq() without ever checking the received report length, dereferencing a fixed buffer at offsets up to byte 285 (P2 branch) or byte 45 (gen3 branch). A malicious or malfunctioning Bluetooth peripheral advertising the Wacom VID/PID can send an undersized report that passes the report-id gate, causing the driver to read past the received buffer and forward the out-of-bounds bytes to userspace via evdev (MSC_SERIAL/ABS_MISC/ABS_WHEEL); on transports whose buffer is sized to the small report descriptor, the over-read can also crash the kernel. An attacker within Bluetooth range gains kernel memory disclosure and possible denial of service, with no privileges or user interaction required. Affected users are those running Linux kernels with the Wacom driver while a compatible Intuos Bluetooth tablet is paired (or a spoofing device is nearby). No public proof-of-concept or exploitation is known; the flaw is fixed upstream by adding a minimum-length guard before parsing.

Do: Update to a Linux kernel that includes the upstream fix adding minimum report-length validation (286 bytes for the INTUOSP2_BT/INTUOSP2S_BT branch, 46 bytes for the gen3 branch) in wacom_intuos_pro2_bt_irq, expected in mainline and stable trees. Users who cannot patch should disable Bluetooth when unneeded and only pair trusted peripherals, since the attack requires an attacker-controlled or spoofed Bluetooth HID device. After patching, treat the driver's new short-report warnings in the kernel log as indicators of attempted abuse.