Vulnerabilities

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.

CVE-2026-89998 is a race condition (invalid memory access) in the Linux kernel's device-mapper (dm) subsystem. It is triggered when userspace issues two concurrent table-load ioctls and one succeeds while the other fails: dm_setup_md_queue walks the md->table_devices list without holding a lock, and if this walk races with dm_table_destroy -> free_devices -> dm_put_table_device, the kernel accesses freed memory. A local attacker with low privileges who can reach the device-mapper control interface could potentially crash the system or achieve memory corruption with high confidentiality, integrity, and availability impact per the CVSS score. Any Linux system running a kernel with the device-mapper table-load code (i.e., broadly all mainstream kernels, including systems using LVM, dm-crypt, or multipath) is affected until patched. No public proof-of-concept is known and the flaw is not listed in CISA's KEV, so no exploitation has been reported.

Do: Update the Linux kernel to a version that includes the dm fix extending the lock over the table_devices list walk in dm_setup_md_queue. As a compensating measure, ensure /dev/mapper/control keeps restrictive permissions (root-only, the distribution default) and audit for local users or containers with access to it. Check your vendor's kernel changelog for the 'dm: fix race when loading and unloading a table' commit before deploying.

CVE-2026-89997 is a race condition in the Linux kernel's device-mapper (dm) core that can cause a mapped device to be resumed after it has already been suspended for destruction. It is triggered when a local user issues the resume ioctl and the remove ioctl concurrently on a device-mapper device, so the table is destroyed without the required postsuspend method being called. Because dm targets expect to be removed only after postsuspend, breaking this invariant causes misbehavior in various targets; for example, in dm-integrity the reboot notifier is not unregistered, leading to a kernel use-after-free that a low-privileged local user could potentially leverage for privilege escalation or a crash. Any Linux system running a kernel with the vulnerable dm code is affected, with the sharpest impact on configurations using dm-integrity or other targets that rely on postsuspend cleanup. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not listed in CISA's KEV catalog.

Do: Update to a vendor or kernel.org release that includes the 'dm: fix resume-vs-remove race' patch (fixed version numbers were not provided in the source data, so track your distribution's security advisory or stable-tree backport). Until patched, restrict local access to device-mapper devices such as /dev/mapper/control to trusted users only. Watch for kernel logs showing dm-integrity or other target misbehavior/crashes after concurrent dm operations as an indicator of exposure.

In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/[email protected]/

A refactoring bug in the Linux kernel's dma-direct subsystem left dma_direct_alloc_from_pool() returning a CPU (virtual) address instead of a struct page pointer, while one of its callers, dma_direct_alloc_pages(), still expects and uses a struct page * — a classic type-confusion that corrupts kernel memory when hit. The flaw is triggered when a DMA allocation falls back to the coherent/atomic memory pool, for example under memory pressure or on systems with constrained DMA addressing. An attacker able to reach the vulnerable allocation path (scored as requiring adjacent-network access, e.g. via a driver-facing code path, with no privileges or user interaction) could achieve kernel memory corruption leading to information disclosure, privilege escalation, or a system crash (CVSS 3.1: 8.8 High). Any Linux system running a kernel built from code containing commit 5b138c534fda, which factored out the dma_direct_alloc_from_pool() helper, is potentially affected until a kernel containing the fix. Exploitation status is currently clean: no public proof-of-concept, no known in-the-wild exploitation, and the flaw is not in CISA's KEV catalog.

Do: Update Linux kernels to releases that include the fix (which restores struct page * returns from dma_direct_alloc_from_pool() and passes the CPU address via an out-parameter) as they appear in mainline, stable, and vendor/distro security advisories. Until patched, limit untrusted local code execution and treat devices with exposed driver/kernel attack surfaces as higher risk. Verify your kernel includes commit 5b138c534fda to determine whether your build is in scope.

The fsl-edma DMA driver in the Linux kernel stores a raw pointer to its struct fsl_edma_engine in the ftrace ring buffer and dereferences that pointer when a trace log entry is later printed, but by that time the engine structure may already have been freed, causing the log output to touch stale memory. A local user with access to tracefs can force event injection through the fsl_edma tracepoint inject mechanism and then read the trace buffer, making the kernel dereference the dangling pointer. The demonstrated outcome is a kernel crash (denial of service); the CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N with C:H/I:H/A:H) reflects a local, low-privilege attack vector, though no privilege-escalation path is described in the fix. Only systems running Linux on NXP/Freescale eDMA hardware (i.MX-class SoCs) with the fsl-edma driver and its trace events enabled are affected. No public PoC beyond the trigger described in the fix is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Update to a kernel that includes the upstream dmaengine fsl-edma fix, which appends a membase field to the trace event so log output no longer dereferences the possibly-freed pointer. Until patched, keep tracefs/debugfs mounted only for root or a trusted group (the default root-only access confines the issue to privileged local users), and check whether CONFIG_FSL_EDMA and its tracepoints are enabled in kernels deployed on NXP i.MX hardware.

In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.

CVE-2026-89992 is a memory-corruption flaw in the Linux kernel's cpuidle dt_idle_genpd code: dt_idle_pd_alloc() allocates the full device-tree node path with kasprintf() but points pd->name at the kbasename() inside that buffer, and dt_idle_pd_free() then calls kfree() on that interior pointer instead of the start of the allocation. The bug is triggered whenever a device-tree-based CPU idle power domain created through this helper is torn down (e.g., on domain removal or error paths) on ARM-class systems whose CPU idle states are managed via generic PM domains. Freeing a non-start-of-allocation pointer can corrupt slab state, giving a local attacker a route to kernel crashes (denial of service) and potentially privilege escalation, consistent with the CVSS 3.1 score of 8.4 (local vector, no privileges, high confidentiality/integrity/availability impact). Affected systems are Linux kernels containing the dt_idle_genpd code, which is used on various ARM SoC platforms such as Android and embedded devices rather than typical x86 servers. There is no evidence of exploitation: the flaw is not in CISA KEV and no public proof-of-concept is known.

Do: Update affected devices with a kernel that includes the upstream patch 'cpuidle: dt_idle_genpd: kfree() the original name allocation' as it reaches your distro or SoC vendor's kernel branches. Until patched, limit untrusted local code execution on ARM devices using DT-based CPU idle power domains, since there is no known workaround and no active exploitation has been observed.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix infinite loop in pcpu_freelist push with one possible CPU __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused.

CVE-2026-89990 is a use-after-free in the Linux kernel's Ceph filesystem (CephFS) client: ceph_mds_check_access() walks the mdsc->s_cap_auths array without holding mdsc->mutex, while MDS session OPEN handling can replace that array and free the old array and its strings under the same mutex. The flaw is triggered when an MDS session is reopened concurrently with a process opening files on a CephFS mount; the fix commit's crash trace shows a php-cgi process faulting in ceph_atomic_open via path_openat after the array was freed beneath it. The demonstrated impact is a kernel oops (denial of service), and as a kernel-space use-after-free it may be exploitable further, consistent with the critical 9.8 CVSS score. Any Linux host mounting CephFS with a kernel containing the vulnerable access-check code is affected. No public proof-of-concept or confirmed malicious exploitation is known and the flaw is not in CISA KEV; it is fixed by a mainline kernel commit pending vendor backports.

Do: Patch kernels on hosts that mount CephFS (verify with 'mount -t ceph') as soon as a fixed mainline kernel or vendor backport is available, prioritizing multi-user systems such as web servers running php-cgi where local processes can race session reopens. Until patched, restrict untrusted local access to CephFS-mounted hosts or unmount CephFS, and be aware that MDS failover/session-reopen events can trigger the race.

In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.

CVE-2026-89988 is a use-after-free race condition in the Linux kernel's kprobes subsystem: the function __within_kprobe_blacklist() walks the kprobe_blacklist list without holding kprobe_mutex, and when a module is unloaded, kprobe_remove_area_blacklist() removes its blacklist entries and frees them immediately with kfree(), so a concurrent blacklist check can dereference freed memory. The flaw is triggered whenever a kernel module is unloaded while another path checks the blacklist, including atomic or non-preemptible contexts where the sleeping mutex cannot even be taken. An attacker with local low-privilege access who can trigger module unloading alongside kprobe blacklist lookups could crash the kernel or potentially exploit the freed-memory window for privilege escalation, consistent with the CVSS score of 7.8 (high) with high confidentiality, integrity, and availability impact. Any Linux system running a kernel with kprobes enabled and the pre-fix code is affected; the exposed impact in practice depends on whether modules are unloaded at runtime. No public proof-of-concept is known, the issue is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.

Do: Track stable and vendor kernel updates for the backported RCU-protected kprobes patch and deploy it as soon as your distribution ships it; no specific fixed version number is available yet. In the interim, restrict untrusted local shell access on production hosts and avoid unloading kernel modules on systems where unprivileged users may be running, since the race requires concurrent module unload and blacklist lookups. Verify whether CONFIG_KPROBES is enabled in your running kernel's configuration to gauge relevance.

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way.

The Linux kernel's alloc_pages_bulk_weighted_interleave() hardcodes GFP_KERNEL when allocating a temporary weights array, even when it is invoked from atomic (non-sleeping) contexts. The bug is reached when an rhashtable rehash under rcu_read_lock() requests a GFP_ATOMIC bucket-table allocation that goes through vmalloc, and the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, causing the kernel to attempt a sleeping allocation in an invalid context (a 'might sleep' splat). A local attacker with low privileges who can set a weighted-interleave memory policy could trigger kernel warnings and potential instability or denial of service. Any Linux system running a kernel containing the weighted-interleave mempolicy code is affected in principle, though triggering requires that specific policy to be in use, which is mostly seen on NUMA/multi-node servers. No public proof-of-concept or exploitation is known, and the flaw is not on the CISA KEV list.

Do: Track your distribution's kernel advisory and update to a kernel that includes the upstream mm/mempolicy fix once backported. As an interim measure, avoid setting MPOL_WEIGHTED_INTERLEAVE memory policies on affected multi-node systems and limit unprivileged local users' ability to set custom mempolicies. Check kernel logs for 'sleeping function called from invalid context' splats referencing bucket_table_alloc or vmalloc paths as indicators of attempted triggering.

The Linux kernel's memory cgroup (memcg) subsystem contains a race condition: the object-cgroup reparenting routine (memcg_reparent_objcgs) assumes a folio's objcg always belongs to the folio's NUMA node, but folio migration across nodes breaks that assumption, leaving objcg reparenting and LRU-list reparenting non-atomic. During the race window, an LRU operation on a migrated folio resolves its lock through the objcg and takes the lru_lock of the wrong memcg rather than the lock of the list the folio actually sits on, corrupting lock/list consistency. An attacker is a local user (per the CVSS local, low-privilege vector) able to induce charge/migration/reclaim activity on a system where cross-node folio migration occurs, potentially gaining kernel memory disclosure or corruption and, per the C:H/I:H/A:H scoring, privilege escalation or denial of service. Affected systems are Linux hosts with memory cgroups enabled, most plausibly multi-NUMA machines such as servers and cloud instances running untrusted local workloads. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known.

Do: Apply a kernel update containing the fix once it reaches the stable branches you track (kernel.org stable trees and your distro's patched kernel packages), and prioritize multi-NUMA hosts that host untrusted local users or multi-tenant workloads. Until patched, restrict local shell access on multi-tenant NUMA servers and confirm exposure by checking NUMA topology (e.g., number of NUMA nodes reported by the platform) and whether memory cgroups are in use; verify the fix is present by confirming the memcg objcg is re-derived on migration in mem_cgroup_migrate()/mem_cgroup_replace_folio().

In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.

In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.

In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.

In the Linux kernel, the following vulnerability has been resolved: arm64: Don't read GMID_EL1 when MTE is disabled __cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task! Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE. Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too.

The Linux kernel's ALSA harmony driver, the sound driver for HP PA-RISC machines, registered its interrupt request in snd_harmony_create() before initializing the h->lock and h->mixer_lock spinlocks, so a pending interrupt could invoke the IRQ handler while the locks were still uninitialized. This race is triggered when an interrupt arrives in the window between IRQ registration and lock initialization, typically during driver probe or boot. A local attacker able to trigger or time this race could cause kernel crashes or memory corruption, potentially yielding denial of service or privilege escalation, consistent with the CVSS 8.4 local-vector score. Only systems running Linux on the HP PA-RISC architecture with the Harmony audio driver built and enabled are affected; mainstream x86 and ARM deployments do not include this driver. There is no known exploitation, no public proof-of-concept, and the issue is not listed in CISA's KEV catalog.

Do: Apply the upstream kernel patch (initialize both locks before requesting the IRQ) via your stable kernel update channel. Inventory for any HP PA-RISC/HP 9000 systems running Linux and check whether the harmony ALSA driver is enabled; as an interim measure, disable or avoid CONFIG_SND_HARMONY if patching is not immediately possible. x86/ARM and other mainstream architectures are not affected.

The Linux kernel's ALSA PCM subsystem contains a race condition in which atomic operations, specifically the trigger (START) command, can run concurrently with non-atomic operations such as hw_params, hw_free, and prepare, because the state checks at the start of those operations do not block atomic ops issued mid-operation. A local attacker who can open a PCM device could trigger this with two threads manipulating the same stream, for example one thread re-issuing PREPARE or HW_PARAMS on an already-prepared stream while another thread triggers START, producing kernel state inconsistency such as the ODEBUG warnings reported by syzkaller and potentially further memory-safety problems. The issue requires low local privileges and no user interaction, and CVSS rates confidentiality, integrity, and availability impact as high, although the kernel developers note serious consequences are usually limited. Any Linux system where untrusted local code can access ALSA PCM device nodes (/dev/snd) is affected, including desktops, embedded/Android devices, and containers or VMs with sound devices exposed. No public proof-of-concept is known, the flaw is not in CISA's KEV, and no in-the-wild exploitation has been reported.

Do: Install a kernel update containing the upstream ALSA PCM race fix (which uses runtime->buffer_accessing to reject trigger-start while hw_params/hw_free/prepare is in progress) as it reaches your distribution's stable branches. Until patched, restrict access to /dev/snd from untrusted users and avoid exposing sound devices to containers or VMs, and monitor vendor advisories for the specific fixed kernel versions for your branch.

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.

In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.