Vulnerabilities

The Linux kernel clock driver for Amlogic Meson GXBB SoCs declares a hard-coded number of parent clocks for the gxbb_32k_clk_sel mux that no longer matches the actual parent array after commit 7915d7d5407c dropped a non-existent clock parent, causing a global out-of-bounds read (8 bytes past gxbb_32k_clk_parents) in __clk_register(). The bug triggers automatically at boot when the GXBB clock driver probes on affected hardware, as observed via KASAN on a WeTek Hub running kernel 7.0.0-rc5. An attacker exposed to the leaked data could read adjacent kernel memory (e.g., neighboring clock names), and a malformed read path can crash the kernel, matching the CVSS scores for confidentiality, integrity, and availability. Only Linux systems running on Amlogic GXBB-based boards (e.g., WeTek Hub) whose kernels include the offending commit are affected. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known; the issue was found through kernel debug instrumentation rather than by attackers.

Do: Update the Linux kernel to a version incorporating the fix that replaces the hard-coded parent count with ARRAY_SIZE() for gxbb_32k_clk_sel, including stable-branch backports when available. If you run upstream kernels on Amlogic GXBB hardware, check whether your build includes commit 7915d7d5407c and monitor for boot-time KASAN/warning output. Risk is limited to local kernel memory disclosure or boot-time crashes; there are no known mitigations short of updating the kernel.

In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.

In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.

The Linux kernel's ASoC (ALSA System on Chip) Loongson sound card driver failed to check the return value of device_property_read_string() when parsing the 'codec-dai-name' ACPI property in loongson_card_parse_acpi(). If that property is missing or invalid, an uninitialized pointer is subsequently used, causing undefined behavior in the kernel, up to and including crashes or memory corruption consistent with the High CVSS score. The flaw triggers when the Loongson sound card driver probes on a LoongArch system whose ACPI firmware does not supply a valid 'codec-dai-name' property. A local attacker able to influence driver probing or firmware property data could gain kernel-level impact (crash or potential privilege escalation), though no exploit path has been demonstrated publicly. Only LoongArch-based Linux systems running kernels with the Loongson ASoC machine driver are affected, and no exploitation, KEV listing, or public proof-of-concept is known.

Do: Update LoongArch systems to a kernel containing the fix commit for CVE-2026-89943 and monitor your distribution's security advisories (no fixed version number is provided in the available data). As a mitigation, ensure ACPI firmware supplies a valid 'codec-dai-name' property, or blacklist/disable the loongson ASoC sound module on systems where onboard audio is not required. Verify exposure by checking whether your LoongArch kernels build and load the sound/soc/loongson driver.

A local use-after-free exists in the Linux kernel Industrial I/O (IIO) subsystem's handling of anonymous buffer handles. An anonymous buffer holds a reference to its underlying IIO device and drops that reference in the buffer's release function, but the function holds the device's buffer mutex via a guard whose unlock occurs after iio_device_put(). If the device has been unbound or hot-unplugged and the anonymous buffer holds the device's last reference, releasing it frees both the IIO device and the buffer containing the mutex, and the subsequent mutex unlock touches freed memory. A local attacker able to trigger device unbind or hot-unplug while dmabuf anonymous buffers are in use could exploit the race for kernel memory corruption, with potential for privilege escalation, data corruption, or denial of service (CVSS 7.8, local vector with high C/I/A impact). Affected are Linux systems running kernels with the IIO anonymous/DMABUF buffer support and IIO devices present; no public proof-of-concept or in-the-wild exploitation is known, and the issue is not listed in CISA KEV.

Do: Update the kernel to a release that includes the fix commit 'iio: buffer: Fix potential use-after-free in anonymous buffer release' once your vendor ships a patched build, and apply stable backports as they are published. As interim mitigation, restrict unprivileged access to IIO device nodes (/dev/iio:device*) and avoid unbinding or hot-unplugging IIO devices while applications hold dmabuf/anonymous buffers. Monitor vendor advisories for the specific fixed version numbers for your distribution.

The Linux kernel's Industrial I/O (IIO) subsystem freed its custom iio_dma_fence objects with a plain kfree() inside a custom release callback, violating the dma_fence core rule that custom releases must be RCU-safe; as a result a fence can be freed while another thread still references it under RCU, producing a use-after-free. It is triggered locally by code that drives IIO DMA buffers through the DMABUF interface and races the fence signaling and release path. A local attacker with low privileges could potentially exploit the UAF for memory disclosure, memory corruption, or a crash (CVSS C:H/I:H/A:H), making local privilege escalation or denial of service plausible. Only kernels carrying the iio_dma_fence code — IIO DMABUF buffer support, mainly relevant to embedded, industrial, and software-defined-radio devices with suitable IIO drivers — are affected; specific version ranges are not stated in the available data. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists as of this advisory.

Do: Update to a stable kernel that includes the upstream commit 'iio: buffer: Make IIO DMA fence release RCU-safe' or your vendor's backport once published; no specific fixed version numbers are given in this data, so check kernel.org stable trees and distro advisories for backport status. Until patched, restrict untrusted local shell access on systems running IIO DMA-capable drivers, and consider unloading or blacklisting the affected IIO DMABUF buffer modules on multi-user hosts.

The Linux kernel's Industrial I/O (IIO) subsystem contains a use-after-free in its DMABUF-based buffer handling: the iio_dma_fence implementation uses a lock embedded in the iio_dmabuf_priv structure, but the fence can outlive that structure, so the lock may be accessed after it has been freed. The flaw is triggered locally by a low-privileged user interacting with the IIO DMA buffer interface such that fence operations race with release of the underlying private buffer object. A successful local attacker could corrupt kernel memory to gain elevated privileges (high confidentiality, integrity and availability impact per the CVSS local-attack vector). Affected are Linux kernel builds that include the IIO DMA buffer/dmabuf support prior to the upstream fix, which ties the lock's lifetime to the fence itself; the advisory does not list specific affected version ranges. No public proof-of-concept is known and the flaw is not listed in CISA's KEV, so no exploitation is currently confirmed.

Do: Update to a kernel that includes the upstream IIO fix (obtained via your distribution's security channel, as no fixed version number is given in the advisory). Restrict unprivileged access to /dev/iio:device* nodes on systems with DMA-capable IIO hardware, and treat local code-execution risk on multi-user embedded/industrial devices as the priority for patching; no public exploit is currently known.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.

The Linux kernel's atlas-sensor driver (drivers/iio/chemical), which supports Atlas Scientific I2C chemical sensor modules, contains a use-after-free during driver teardown. Its threaded data-ready IRQ handler defers work to an irq_work that calls iio_trigger_poll(), but because the IRQ is devm-managed, free_irq() runs during devres cleanup after atlas_remove() returns without flushing that pending work. If a buffer is enabled and conversion-complete IRQs keep firing, a queued irq_work can execute after atlas_data, the IIO device, and the trigger have been freed, and the handler then dereferences freed memory via container_of(). A local attacker able to enable a sensor buffer and unbind or unload the driver could potentially crash the kernel or escalate privileges (CVSS 7.8, local, low privileges). Only systems running kernels with this driver enabled and the corresponding Atlas Scientific sensor hardware attached are affected; no public exploit is known, the issue is not in CISA KEV, and it was found by an in-house static analysis tool rather than observed exploitation.

Do: Update to a Linux kernel that includes the upstream fix using iio_trigger_poll_nested() in the atlas-sensor threaded IRQ handler. As an interim mitigation, do not unbind or rmmod the atlas-sensor module while a sensor buffer is enabled. Check whether your kernel config enables the Atlas sensor IIO driver and whether such hardware is attached; if not, you are not affected.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.

In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.

In the Linux kernel, the following vulnerability has been resolved: iio: light: apds9306: fix PM reference leak in apds9306_read_data() apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths.

In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.

In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe. The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup.

CVE-2026-89932 is a guest-isolation flaw in the Linux kernel's KVM nested virtualization (nVMX) code: when vpid02 (the VPID used for a nested guest) is freed on VMXOFF and later reallocated, KVM does not reset its last_vpid tracking, so the VPID is not flushed on first use. The flaw is triggered when an L1 guest performs VMXOFF followed by VMXON, runs an L2 guest, and KVM happens to reuse a VPID whose stale TLB entries still exist on the physical CPU. An attacker controlling a guest could cause the hypervisor to use stale TLB mappings from a previous lifetime of that VPID, potentially associated with a different vCPU or an entirely different VM, breaking isolation and enabling cross-VM/cross-vCPU memory disclosure with potential integrity and availability impact (CVSS 8.8). Any Linux host running KVM with Intel nested virtualization (nVMX) enabled and untrusted guests is affected. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not in CISA KEV.

Do: Apply a kernel update from your distribution that includes the nVMX fix (no fixed version numbers were provided in the advisory, so track vendor kernel releases for the 'KVM: nVMX: Always flush vpid02 on first use' commit). As an interim mitigation on hosts running untrusted workloads, disable nested virtualization (e.g., set kvm_intel nested=0 or otherwise prevent guests from using VMX). Audit which hosts expose nested VMX to guests and whether multiple untrusted VMs share those hosts, since VPID reuse is the trigger condition.

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.

CVE-2026-89930 is a missing TLB flush in the Linux kernel's KVM hypervisor, specifically in the nVMX code that implements Intel nested virtualization. When a guest hypervisor (L1) attempts to launch a nested guest (L2) and the VM-Entry fails (e.g., due to failed VMCS checks or an MSR load list that architecturally requires a TLB flush), KVM skips servicing queued local TLB flushes while still updating its record of the last VPID used by L2, so a subsequent successful VM-Entry misses the required flush. A malicious guest can trigger this by changing L2's VPID, forcing a failed VM-Entry followed by a successful one, causing stale TLB translations to be reused, which can break guest isolation with high confidentiality, integrity, and availability impact (CVSS 9.3, scope changed). Only hosts running Linux with KVM and nested virtualization enabled, where tenants can run their own VMs inside a guest, are practically affected. No public proof-of-concept or in-the-wild exploitation is known, and the flaw is not in CISA's KEV catalog.

Do: Upgrade to a Linux kernel that includes the upstream nVMX fix ('KVM: nVMX: Service local TLB flushes on failed nested VM-Enter') as delivered in stable-series kernel updates. Until patched, disable nested virtualization for KVM (e.g., set nested=0 for the kvm_intel module) or restrict which tenants may run nested VMs; check current state at /sys/module/kvm_intel/parameters/nested. With no public exploit or KEV listing, prioritize patching multi-tenant virtualization hosts where guests are semi-trusted.

A flaw in the Linux kernel's KVM nested virtualization (nVMX) code causes the INVVPID TLB-invalidation instruction to be emulated on the wrong physical CPU: when an L1 guest migrates between physical CPUs, KVM may execute INVVPID on the CPU the vCPU thread is currently scheduled on rather than the CPU where the nested guest (L2) last ran, leaving stale TLB entries behind. An attacker with low privileges inside a guest (L1 or L2) can trigger this via crafted guest TLB-flush behavior and potentially retain access to stale address translations across guest security boundaries, risking information disclosure, data tampering, or denial of service on the host (CVSS 8.8 High, scope changed). Any Linux host running KVM on Intel hardware with nested virtualization enabled and a nested guest workload is affected. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known; a fix has been committed upstream.

Do: Update to a kernel containing the upstream nVMX INVVPID fix (mainline and stable trees; watch for your distribution's backport). As a mitigation, disable nested virtualization on hosts that do not need it (e.g., set kvm_intel nested=0), and prioritize patching multi-tenant hosts where untrusted guests can run nested VMs. Audit which KVM hosts run Intel CPUs with nested VMX workloads to gauge your exposure.

A race condition in the Linux kernel's KVM x86 MMU lets the lockless reverse-map (rmap) walk used by kvm_rmap_age_gfn_range() traverse an rmap chain without holding its lock, because __kvm_rmap_lock() deliberately elides locking when the rmap reads as empty while the aging path ignores the lock's return value and re-reads the rmap head. If a writer populates the rmap between those two reads, the aging path — which runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y — can follow a pte_list_desc chain that a writer holding mmu_lock frees via kmem_cache_free() mid-walk, producing a slab use-after-free. A local, low-privileged attacker able to drive KVM memory-management operations (CVSS 8.8, AV:L/AC:L/PR:L/S:C) could potentially achieve kernel memory corruption and disclosure, privilege escalation, or a host crash, with high confidentiality, integrity and availability impact. Any hypervisor host running VMs on a Linux kernel with the KVM lockless rmap-aging code enabled is affected. No public proof-of-concept is known and the flaw is not in CISA KEV, so no in-the-wild exploitation is currently known.

Do: Update hypervisor hosts to a kernel containing the upstream KVM fix (which makes lockless walkers consume the value returned by kvm_rmap_lock_readonly() instead of re-reading the rmap) or a distribution backport when available. Until patched, avoid enabling CONFIG_KVM_MMU_LOCKLESS_AGING on multi-tenant hypervisor hosts and restrict unprivileged local access to VM hosts. Monitor kernel.org and vendor security advisories for fixed builds.

KVM's emulation of Hyper-V synthetic timers (SynIC's four per-vCPU stimers programmed via the HV_X64_MSR_STIMERi_CONFIG/COUNT MSRs) can overflow when COUNT is near U64_MAX, producing an absolute deadline in the past. An unprivileged guest process issuing WRMSR, or host userspace setting the MSR via KVM_SET_MSRS, can arm the timer so that it immediately fires and is endlessly re-armed, causing vcpu_enter_guest() to abort and loop without ever running the guest. The result is a CPU livelock in which a SCHED_FIFO host task starves RCU grace-period kthreads, producing RCU stalls and a host-side denial of service (no code execution or data impact). Any x86 Linux host running KVM with Hyper-V SynIC/stimer emulation exposed to a guest is affected, which includes most multi-tenant cloud hosts and systems running Windows or Hyper-V-enlightened Linux guests. No public proof-of-concept is known and the issue is not listed in CISA KEV.

Do: Patch KVM hosts with kernel updates that include the stimer deadline clamp fix, prioritizing multi-tenant environments where guests can run arbitrary code. As interim mitigation, avoid exposing Hyper-V SynIC/stimer enlightenments (e.g., hv-synic CPU flags / Hyper-V MSR exposure) to untrusted tenants, and monitor host logs for RCU stall and hrtimer warnings on cores running KVM vCPU threads.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.

A race condition leading to a use-after-free exists in the Linux kernel's KVM implementation for the s390/s390x architecture: the __import_wp_info() helper backs up guest memory contents for hardware watchpoints via read_guest_abs() without holding the KVM SRCU lock, so a concurrent memslot update can free the memslots array once its SRCU grace period elapses. It is triggered from host kernel context by local code with access to /dev/kvm (e.g., a process importing guest-debug watchpoint data) that races a memslot update. A successful attacker corrupts host kernel memory, yielding high confidentiality, integrity and availability impact, i.e., potential host privilege escalation (CVSS 7.8, local, low privileges required). Only operators of Linux KVM hosts on IBM Z / LinuxONE (s390x) hardware are affected; KVM on x86 and other architectures is not implicated. No public proof-of-concept or in-the-wild exploitation is known, the flaw is not in CISA's KEV catalog, and a fix has been merged upstream in the kernel.

Do: Update s390x KVM hosts to a kernel release that includes the upstream 'KVM: s390: Take srcu when importing watchpoint data' fix (check your vendor's kernel advisories and stable/long-term trees, as no fixed version number is given in the source data). Until patched, restrict /dev/kvm access to trusted management processes and avoid guest-debug hardware watchpoint features on s390x hosts. Operators of x86/ARM KVM hosts need no action.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.

The Linux kernel's KVM implementation for the s390 (IBM Z) architecture incorrectly re-injects channel-subsystem (CK) damage machine checks into running guests, even though the guest channel subsystem is emulated in the userspace VMM and such checks concern only the host channel subsystem. During reinjection the code could also free (kfree) a stack variable, causing kernel memory corruption; the fix masks the CK bit in s390_backup_mcck_info() and stops forwarding these machine checks to guests. An attacker with low local privileges could potentially leverage the resulting memory corruption for privilege escalation or broader kernel compromise (scope change per the CVSS vector), though high attack complexity limits practical exploitability since it depends on hardware-reported machine-check events. Only Linux systems running on s390/IBM Z hardware as KVM hosts are affected. No public proof-of-concept or in-the-wild exploitation is known, and the flaw is not listed in CISA's KEV catalog.

Do: Update to a kernel containing the upstream fix or your distribution's patched s390x kernel once released; check kernel and distro security advisories (SUSE, Red Hat, Canonical, Debian) for backports. Only IBM Z systems acting as KVM hosts need to act, and no workaround is described, so patching is the only remediation. All other architectures (x86, ARM, PowerPC, etc.) are unaffected.

CVE-2026-89919 is a locking race condition in the Linux kernel's KVM implementation for the s390 (IBM Z / LinuxONE) architecture. The KVM_S390_KEYOP handler reads the guest address-space control element (gmap->asce) without holding the MMU read lock, unlike every other dat_* consumer in the file, while gmap_set_limit() mutates the same field under the MMU write lock in response to KVM_S390_VM_MEM_LIMIT_SIZE. If a low-privileged local user invokes KVM_S390_KEYOP concurrently with a change to the VM's memory limit, keyop can walk guest memory using a stale asce value, corrupting host kernel memory. Successful exploitation yields high-impact corruption of host memory (confidentiality, integrity, and availability per the CVSS 7.8 score), which can crash the host or potentially be leveraged for privilege escalation. Only Linux KVM hosts on s390x hardware are affected; no public proof-of-concept exists, the flaw is not in CISA's KEV catalog, and no in-the-wild exploitation is known.

Do: Update s390x hosts to a kernel package containing the KVM s390 keyop mmu_lock fix as soon as your vendor ships it, and verify the running kernel version after patching. Until then, restrict access to /dev/kvm (and KVM ioctl privileges) to trusted users on IBM Z hosts and avoid running KVM_S390_KEYOP operations concurrently with changes to a guest's memory limit size (KVM_S390_VM_MEM_LIMIT_SIZE).

The KVM hypervisor code in the Linux kernel for ARM64 computes TLB invalidation ranges by comparing an address against (base + size), and this arithmetic wraps around to zero when the range covers the very last page or block of the TTBR1 virtual address space, so the comparison fails and the TLB entry is never invalidated. A local attacker, typically code running inside a KVM guest, can trigger unmapping and invalidation at the top of the address space so that stale TLB entries survive, leaving memory that was unmapped (and may be reused by the host or another VM) reachable, which is a confidentiality, integrity and availability issue across security boundaries and earns the 9.3 critical CVSS score with scope change. Only ARM64 Linux kernels running KVM virtualization are affected; x86 KVM and ARM64 systems without KVM are not. There is no public proof-of-concept, the issue is not listed in CISA's KEV catalog, and no in-the-wild exploitation is currently known.

Do: Patch ARM64 KVM hosts with kernel updates that include the 'Correctly handle end of VA space TLBI invalidation' fix as soon as vendor or stable-tree releases ship it, and because no fixed version number is given in the data, match by patch commit or kernel changelog rather than version. Until patched, limit untrusted or multi-tenant guest workloads on ARM64 KVM hosts and monitor vendor advisories for backported fixes.

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set.

A race condition in the Linux kernel's KVM hypervisor for arm64 lets one virtual CPU install a TLB entry for a page that has just been invalidated by another vCPU, because VNCR (nested-virtualization) invalidation did not participate in the MMU invalidation retry/sequencing mechanism. It is triggered when one vCPU walks the stage-1 page tables to translate a VNCR access while a second vCPU concurrently replaces that mapping with an invalid entry and issues a TLBI S1E2, allowing the first vCPU to cache a now-stale mapping. An attacker able to run or influence nested virtualization workloads on an affected arm64 host could retain and use stale mappings to freed or reassigned memory, with critical confidentiality, integrity, and availability impact across VMs (CVSS scope changed). Affected users are operators of arm64 Linux hosts running kernels with KVM and nested-virtualization (NV/VNCR) support, such as Ampere Altra, AWS Graviton, or similar ARM server/cloud deployments running nested guests. No public proof-of-concept or in-the-wild exploitation is known; the flaw has been fixed by an upstream kernel commit.

Do: Update arm64 KVM hosts to a kernel that includes the upstream KVM/arm64 fix as it propagates to the stable branches; until patched, avoid running nested (NV/VNCR) guests or restrict /dev/kvm access to trusted users only. Check whether your kernel enables KVM arm64 nested virtualization, as the flaw is only reachable through the VNCR/nested-guest code path.

CVE-2026-89915 is a correctness flaw in the Linux kernel's KVM implementation for arm64 nested virtualization: a VM-wide counter tracking whether a guest (L1) hypervisor's VNCR page is mapped in the host (L0) is unreliable, causing the host to skip required TLB invalidations and leave stale translations in place. It is triggered by ordinary nested-virtualization activity, most commonly an L1 vCPU invalidating its own TLBs at a point where the VNCR page is not actually mapped in L0, so the counter-based check misses needed invalidations of the VNCR 'pseudo-TLB'. A malicious local guest could potentially exploit stale mappings to read or corrupt memory beyond its intended scope or to destabilize VMs, consistent with the CVSS scoring of high confidentiality, integrity and availability impact with a changed security scope. Only arm64 Linux hosts running KVM with nested virtualization (VNCR/NV2) on supporting hardware are affected; hosts that never run nested guests are not exposed to this code path. No public proof-of-concept or in-the-wild exploitation is known, and the fix, which removes the flawed counter entirely, has been merged in the mainline kernel.

Do: Update affected arm64 hosts to a kernel that includes the upstream fix (removal of the VM-wide VNCR mapping counter) or to your vendor's patched kernel when it becomes available. Until then, avoid enabling nested virtualization for guests on arm64 KVM hosts and audit whether any L1 guests run their own VMs. Restrict untrusted tenants on multi-tenant arm64 virtualization hosts as a precaution.

A missing sign-extension of the virtual address in the arm64 KVM range-based TLB invalidation helper (decode_range_tlbi()) causes the Linux kernel hypervisor to compute incorrect invalidation ranges for Stage-1 TLBI operations on 64-bit ARM hosts. The flaw is triggered when a guest issues range-based TLB invalidation instructions that are decoded by the host kernel, leaving stale TLB entries that should have been flushed; the fix also notes PA-bit overflow must be avoided for Stage-2 invalidation. An attacker can potentially read or modify memory that should have been unmapped, breaking isolation between the host and guests, consistent with the scope-changed critical CVSS rating (high confidentiality, integrity and availability impact). Affected users are operators of Linux kernels with the arm64 KVM range-TLBI code, chiefly ARM server, cloud and virtualization hosts running untrusted local workloads. 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: Update affected arm64 hosts to a kernel that includes the KVM arm64 sign-extension fix for range-based TLBI (track stable-kernel and your distribution's security updates, as no fixed version number is given in this advisory). Until patched, avoid running untrusted local workloads or guests on arm64 KVM hosts and verify with your vendor whether your running kernel contains the fix. Because no PoC or in-the-wild exploitation is known, a routine patching cadence is sufficient for most deployments.

CVE-2026-89913 is a reference-counting/use-after-free flaw in the Linux kernel's KVM hypervisor for 64-bit ARM (arm64), in the vgic-v3 code that saves pending-interrupt tables for GICv3 ITS virtual interrupts (LPIs). The function vgic_v3_save_pending_tables() iterates the xarray of LPI entries and dereferences each one without taking a reference; the iterator only provides temporary RCU protection, which is insufficient for a loop body that reads interrupt state and performs guest memory accesses. A concurrent path - the irqfd cached-injection path taking a transient LPI reference without holding the relevant locks, combined with a guest issuing an ITS DISCARD command that drops the remaining references - can free the LPI via kfree_rcu(), leaving the iterating code holding and dereferencing a stale pointer after the RCU grace period. An attacker able to run or steer a guest on an affected arm64 KVM host can trigger the race from a low-privileged local position, gaining host-kernel memory corruption leading to denial of service and, per the CVSS score (scope changed, high C/I/A), potentially guest-to-host privilege escalation. Affected users are operators of Linux KVM hosts on arm64 hardware with GICv3 ITS emulation, especially where guests use ITS/LPIs with irqfd-based injection; no public proof-of-concept is known, it is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Patch ARM64 KVM hosts with a kernel that includes this vgic-v3 fix (pick up the latest stable/longterm kernel containing the commit; the data does not name a specific fixed release). Until patched, restrict untrusted guests from using GICv3 ITS with irqfd-based interrupt injection, or avoid that combination on affected hosts. Audit hosts with 'uname -r' plus guest configurations that enable ITS/LPIs and irqfd to determine whether they are in the exposed subset, and watch host logs for KVM/ITS warnings or crashes.

A NULL-pointer dereference in the Linux kernel's KVM/arm64 interrupt-controller emulation (VGIC-ITS) lets a guest crash the host: the MAPC command with V=0 clears an interrupt translation entry's collection pointer while leaving the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. An attacker controlling a guest issues the MAPD, MAPTI and then MAPC(V=0) command sequence - deemed UNPREDICTABLE by the architecture but tolerated by KVM's other paths - and the host kernel oopses when the VMM next issues KVM_DEV_ARM_ITS_SAVE_TABLES during migration. The impact is a local denial of service on the hypervisor host (scope changed from guest to host, availability impact high, no confidentiality or integrity impact). Anyone running Linux KVM on ARM64 hosts with GICv3 ITS emulation is affected, especially multi-tenant or cloud environments that live-migrate guests. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists; a fix is present in the upstream kernel with stable backports.

Do: Update host kernels to a stable release containing the KVM arm64 vgic-ITS fix. Until patched, avoid live migration of untrusted guests with emulated GICv3 ITS (i.e., do not issue KVM_DEV_ARM_ITS_SAVE_TABLES) on multi-tenant ARM64 hosts, and check host logs for kernel oopses in vgic_its_save_ite following migration attempts. The flaw is availability-only, so prioritize hosts running untrusted or multi-tenant ARM64 workloads.

The Linux kernel's KVM implementation for 64-bit ARM (arm64) fails to cap guest-controlled TLB Invalidation by Range (TLBI Range) operations to the architectural limit, allowing an overflow when the invalidation range is added to an arbitrary guest-supplied base virtual address. A low-privileged attacker inside a guest VM can trigger this by issuing crafted TLBI range invalidations that overflow the hypervisor's range computation. Per the CVSS score (7.9, scope changed), the impact crosses the guest-to-host boundary: primarily high impact on host availability, with low confidentiality and integrity impact, meaning a guest can crash or destabilize the host hypervisor and potentially other tenants on it. Anyone running KVM guests on arm64 hosts with hardware supporting the TLBI Range feature is affected. There is currently no public proof-of-concept, no listing in CISA's KEV catalog, and no known in-the-wild exploitation.

Do: Update the Linux kernel on arm64 KVM hosts to a release incorporating the upstream KVM/arm64 TLBI Range capping fix as it is backported into your distribution's stable branches. Until patched, avoid running untrusted tenants on the same arm64 host and watch for host crashes, soft lockups, or hypervisor faults correlated with guest memory-management activity. No mitigation short of the kernel fix is known, since the fault is reachable from a guest by design.

CVE-2026-89910 is an uninitialized stack variable flaw in the Linux kernel's LoongArch KVM implementation: the array vector[] declared in dmsintc_inject_irq() can be read before it has been initialized. It is triggered on LoongArch hosts when KVM performs device/MSI interrupt-controller injection (dmsintc) under conditions where the vector values are never set, reachable by a local user with low privileges who can run or interact with KVM guests. Per the CVSS score of 7.3, a successful trigger primarily risks disclosure of sensitive stack memory (high confidentiality impact) with limited integrity impact and no availability impact. Only systems running Linux kernels with LoongArch KVM support on Loongson/LoongArch hardware are affected; x86 and ARM hosts are not. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists.

Do: Update LoongArch hosts to a kernel that includes the resolved LoongArch KVM fix for dmsintc_inject_irq (track the upstream commit via your distribution's kernel advisories, as no fixed version number is provided in this data). Until patched, restrict the ability to create and run KVM virtual machines on LoongArch hosts to trusted local users. x86 and ARM systems do not carry the affected code and need no action.

In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().

A flaw in the Linux kernel's LoongArch KVM implementation causes memory-slot architecture flags (KVM_MEM_HUGEPAGE_CAPABLE / KVM_MEM_HUGEPAGE_INCAPABLE) to be lost during KVM_MR_FLAGS_ONLY memslot updates, because a zeroed memslot is installed and the old flags are never carried over. The condition is triggered in practice when live migration toggles KVM_MEM_LOG_DIRTY_PAGES on a memslot that had been marked huge-page-incapable due to a GPA/HVA offset mismatch; huge (PMD) mappings are then created even though guest physical and host virtual addresses are not aligned, and the guest ends up accessing the wrong host pages. A local attacker with low privileges inside a guest on such a host can therefore read or corrupt host memory pages belonging outside their VM, yielding high confidentiality, integrity and availability impact with scope change beyond the guest (CVSS 8.8). Only systems running Linux KVM on LoongArch (Loongson) hardware with virtualized guests are affected. No public proof-of-concept, KEV listing, or known in-the-wild exploitation has been reported.

Do: Update LoongArch KVM hosts to kernel versions that include the 'LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY' fix, via mainline or stable backports as available. Until patched, avoid live migration of guests on LoongArch KVM hosts, or provision guest memory so GPA and HVA offsets align within a PMD so memslots remain huge-page-capable. Confirm whether you operate LoongArch (Loongson) hardware with KVM guests before prioritizing, as x86/ARM KVM is unaffected.

The LoongArch KVM implementation in the Linux kernel fails to validate the MSI data value before using it as an interrupt number in the emulated EIOINTC interrupt controller, where values >= 256 cause reads and writes past the end of the ISR bitmap, sw_coremap[], and per-CPU coreisr/sw_coreisr arrays. A local attacker who holds a VM file descriptor can supply the oversized MSI data either through a KVM_IRQ_ROUTING_MSI routing entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI. The result is out-of-bounds kernel memory corruption beyond the loongarch_eiointc allocation, which per the CVSS scope change (8.8 High, AV:L/PR:L/S:C) can lead to kernel code execution, information disclosure, or a host crash. Only hosts running KVM guests on LoongArch (Loongson) hardware are affected; the DMSINTC path is not impacted because it masks the decoded vector. No public proof-of-concept, CISA KEV listing, or reports of in-the-wild exploitation are known.

Do: Update affected LoongArch hosts to a kernel containing the fix that rejects MSI data outside the EIOINTC irq space. Until patched, restrict write access to /dev/kvm on LoongArch machines to trusted VMM processes and audit which users or services hold VM file descriptors. x86 and ARM KVM hosts are unaffected, so verify whether any Loongson/LoongArch hardware in the fleet is running KVM guests before prioritizing.

A flaw in the Linux kernel's LoongArch BPF JIT compiler miscalculates branch offsets for tail calls: the jump distance was derived from a stale code-size stride left over from an earlier JIT pass, so when extra JIT passes run, branches can be emitted with wrong offsets. A local user who can load BPF programs using tail calls can trigger the condition, producing incorrect jumps that hang the machine (soft lockup), i.e., a denial of service; the CVSS 3.1 score (7.8, local vector) assumes high confidentiality, integrity and availability impact from a low-privileged local account. Only systems running Linux on LoongArch (loongarch64) hardware, i.e., Loongson processors, are affected, since other architectures use different BPF JIT code. No public proof-of-concept exists, the issue is not in CISA KEV, and no exploitation has been reported; a fix has been merged in the upstream kernel tree.

Do: Update LoongArch (loongarch64) hosts to a kernel that includes the upstream fix for CVE-2026-89906 (commit 'LoongArch: BPF: Refactor jump offset calculation in tail call'; check your distribution's kernel changelog). As a mitigation, disable unprivileged BPF (kernel.unprivileged_bpf_disabled=1) and monitor loongarch64 machines running tail-call-heavy BPF programs (seccomp filters, tc/XDP, tracing) for soft-lockup reports. No action is needed on non-LoongArch systems.

In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Move arena register slot below TCC context Currently, the stack layout places the optional arena register slot above the tail call counter context. When arena_vm_start is dynamically enabled, it shifts the relative offset of the tcc_ptr slot within the stack frame, causing hardcoded tracking macros to mismatch and leading to memory misalignment or corruption potentially. To fix this, move the arena register save and restore sequences below the tail call counter context slots in both build_prologue() and the epilogue. Update __build_epilogue() to insert a proper offset decrement to safely skip the unneeded tcc_ptr reading block while accurately aligning with the relocated arena slot at the very bottom. With this patch, the tcc_ptr slot is always positioned at a fixed distance directly underneath the base callee-saved registers that is independent of whether the arena features are on.

An array overflow exists in the Linux kernel's LoongArch code: the fixed-size acpi_package_ids[] array is too small for virtual machines that expose up to 256 single-core sockets (packages) via the PPTT ACPI table. When a LoongArch virt machine is booted with such a topology, parsing the PPTT table writes past the end of the array, corrupting adjacent kernel memory. An attacker who can get the kernel to process an oversized package count could crash the machine or potentially achieve kernel memory corruption leading to privilege escalation, consistent with the high confidentiality, integrity, and availability ratings in the CVSS 8.4 local-attack score. Only Linux systems running on the LoongArch (Loongson) architecture are affected — particularly KVM guests with many one-core-per-socket topologies — while mainstream x86 and ARM deployments are not. No public proof-of-concept is known, no exploitation has been reported, and the issue is not in CISA KEV.

Do: Update LoongArch systems to a kernel that includes this fix (mainline/stable release containing the LoongArch acpi_package_ids[] resize, via your distribution's kernel advisory). Until patched, avoid configuring LoongArch virt guests with large numbers of one-core-per-socket packages (up to 256 sockets) that would exceed the array. Check dmesg/ACPI PPTT parsing on affected VMs for anomalies and watch vendor advisories for the backported patch version.

In the Linux kernel's LoongArch rethook/kretprobe trampoline, the percpu base register $r21 is saved at entry and restored at exit, but the handler can schedule via preempt_enable_notrace(); if the task migrates to another CPU in between, restoring the stale percpu base poisons $r21 and makes all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU until the next user-to-kernel transition. Under kretprobe-heavy preemptible load this corrupts scheduler and timer state, causing scheduling-while-atomic splats, wrong-CPU RCU warnings, and CPUs parking in idle with the constant timer never re-armed (hard lockup); it was reproduced on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn. A local actor able to register kretprobes/fprobes (typically via root ftrace/perf/BPF tooling) can trigger denial of service and kernel state corruption, matching the CVSS 7.8 local/high-impact rating. Affected parties are operators of LoongArch (Loongson) systems running Linux since v6.3, where the flaw first appeared in the kretprobe trampoline and was carried into the rethook trampoline. No public proof-of-concept is known and there are no reports of exploitation in the wild; the fix simply removes the save/restore of $r21.

Do: Update LoongArch systems to a kernel that includes the 'LoongArch: Do not save/restore percpu base register in rethook trampoline' fix (stable backports where available). Until patched, avoid kretprobe-heavy tracing (ftrace kretprobes, fprobe, perf/BPF kretprobe hooks) on preemptible LoongArch kernels, especially during I/O-intensive workloads such as OS installs or large archive extraction. Investigate any scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) hits in nohz_balance_exit_idle(), or idle CPUs with non-re-armed tickers as signs of this bug.

The Linux kernel's LoongArch Kprobes support uses the 'break 11' instruction for the single-step breakpoint placed after out-of-line instruction execution, and userspace code can issue the same opcode, so do_bp() reaches kprobe_singlestep_handler() with no active probe. The handler calls preempt_enable_no_resched() before returning false, without the matching preempt_disable() that only a real Kprobe hit performs, underflowing the task's preempt count and making in_interrupt() report true until the task next schedules. A local attacker who traps into a SIGTRAP handler and opens a socket there gets it misattributed to the root cgroup, bypassing a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup, and the underflow can otherwise destabilize the kernel (CVSS 3.1: 7.8, local, low privileges). Only systems running Linux on LoongArch (Loongson) CPUs with Kprobes support are affected; no public PoC or in-the-wild exploitation is known.

Do: Update LoongArch kernels to a build containing the upstream fix, which returns from kprobe_singlestep_handler() immediately when kprobe_running() reports no active probe, via your distribution (e.g., Loongnix, Kylin, UOS, openEuler) or a stable-tree backport. Until patched, avoid running untrusted local code on LoongArch hosts and audit reliance on BPF_CGROUP_INET_SOCK_CREATE policies, since sockets can be misattributed to the root cgroup. Check kernel logs for preempt-count or scheduling warnings following user-triggered SIGTRAP events.

In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

In the Linux kernel, the following vulnerability has been resolved: media: cec: core: Fix kmemleak due to missed rc_free_device() call The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak.

A race condition in the Linux kernel's Consumer Electronics Control (CEC) media subsystem can free a transmit data structure while its delayed timeout work item is still armed, producing a kernel use-after-free (reported as an ODEBUG 'free active' condition in cec_wait_timeout). It is triggered when cec_transmit_msg_fh() drops the adapter lock to wait for a blocking transmit via wait_for_completion_killable() and that wait is interrupted by a signal: cancel_delayed_work_sync() then runs before the CEC kthread arms the reply timeout in cec_transmit_done_ts(), so the delayed work is re-armed after cancellation and the freed data still has pending work. A local low-privileged attacker who can induce signals during CEC transmit operations could corrupt freed kernel memory, with CVSS 3.1 scoring high confidentiality, integrity, and availability impact (7.8), i.e., potential denial of service or privilege escalation. Only Linux systems that use the CEC subsystem are affected in practice — devices with HDMI-CEC capable hardware such as media centers, TV tuners, USB CEC adapters, and embedded set-top style boards; ordinary servers and desktops without CEC hardware are not meaningfully exposed, and the vector is local only. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not on the CISA KEV list.

Do: Apply a Linux kernel update that includes the upstream CEC fix (the commit using disable_delayed_work_sync() in cec_transmit_msg_fh()) once your distribution ships it, since no specific fixed version numbers are available in this data. Restrict unprivileged local access to CEC device nodes (e.g., /dev/cec*) on media/embedded devices to reduce attack surface. No remote or network exposure is associated with this flaw, so no perimeter mitigation is needed.

The Linux kernel's CEC (Consumer Electronics Control) driver for the Extron DA HD 4K Plus HDMI distribution amplifier lacks a sanity check on incoming data, so a malformed message can overflow the msg.msg[] buffer in kernel memory. The flaw is triggered when the driver processes malformed incoming data, such as corrupted responses from the attached Extron device or hostile input injected into the HDMI/CEC chain; the CVSS adjacent-network (AV:A) vector reflects that the attacker must have access to the CEC/HDMI or USB path rather than remote network access. Successful exploitation could corrupt kernel memory with high impact on confidentiality, integrity and availability, potentially causing a crash or kernel code execution. Only Linux systems running a kernel with the extron-da-hd-4k-plus driver enabled and the corresponding Extron hardware attached are affected, which is a very small population. No public proof-of-concept is known, the issue is not in CISA's KEV, and no exploitation has been reported.

Do: Update to a stable Linux kernel that includes the 'media: cec: extron-da-hd-4k-plus: add sanity check' fix commit (check your distro's kernel errata for the backported version). If updating is not possible, avoid attaching untrusted HDMI/CEC source devices to the Extron unit or blacklist/unload the extron-da-hd-4k-plus module. Confirm exposure by checking kernel config for the Extron CEC driver and lsusb for the Extron DA HD 4K Plus device.