Suse
Monthly
Kernel oops and duplicate/incorrect DMA unmapping in the Linux kernel SPI core can occur when __spi_map_msg() partially fails: if the RX scatter-gather mapping fails after the TX mapping succeeds, or if a later transfer's TX mapping fails after earlier transfers were mapped, the tx_sg_mapped/cur_tx_dma_dev bookkeeping is left inconsistent, so the subsequent spi_unmap_msg() may unmap a TX mapping twice or call dma_unmap_sg_attrs() with a NULL or stale device struct. Affected systems are Linux kernels 6.11 through the pre-fix stable trees, and exploitation requires local execution on a platform whose SPI controller performs DMA-mapped transfers (typically embedded/ARM SoC hardware) plus an actual DMA mapping failure, which normally arises only under memory pressure or address-space/IOMMU exhaustion and cannot be induced remotely; no public exploit code was identified at time of analysis. Note that the vendor-supplied CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is severely inconsistent with the technical description and should be treated as boilerplate auto-scoring, not a real signal - the independent assessment is AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H, i.e., a local, high-complexity availability-only defect.
An out-of-bounds read in the Linux kernel's iSCSI target (LIO) login handling lets a remote, unauthenticated initiator read past the end of a heap buffer when the target portal is configured to require CHAP authentication. Because login->req_buf is kzalloc'd with exactly MAX_KEY_VALUE_PAIRS (8192) bytes and iscsit_get_login_rx() accepts payload_length plus padding, a login PDU with DataSegmentLength between 8189 and 8192 fills the buffer completely, leaving no NUL terminator; the buffer is then consumed by length-unaware C string routines such as kstrdup(), strstr() and strlen_semi(), and convert_null_to_semi() rewrites embedded NULs to ';', so adjacent slab memory is walked and disclosed. The flaw is reachable pre-authentication only on portals that explicitly require CHAP (portals that do not require authentication rewrite AuthMethod to None in iscsi_login_zero_tsih_s2() and never enter the CHAP path), requires no user interaction, and at the time of analysis there is no public exploit identified, though a vendor patch is available and the affected kernel versions are broad.
An out-of-bounds write in the Linux kernel's SCSI bsg io_uring completion path allows a local attacker with low privileges (CVSS PR:L) to overrun a user-supplied response buffer that is smaller than SCSI_SENSE_BUFFERSIZE, because the completed sense length is copied back without being capped to the caller's max_response_len. The io_uring-backed bsg passthrough interface that exposes the flaw was introduced in kernel 7.1 and is fixed in 7.2.5 and 7.3-rc2, so exposure is limited to very recent kernels on hosts where a bsg device node is reachable; no public exploit identified at time of analysis. The vendor's CVSS 7.8 (C:H/I:H/A:H) overstates real-world risk - our independent assessment scores it C:N/I:L/A:H, with the impact largely a memory-corruption/denial-of-service concern rather than a full confidentiality breach.
Local privilege escalation in the Linux kernel's SCSI bsg io_uring passthrough path (bsg_uring_cmd) allows an authenticated low-privileged local user (PR:L) to corrupt kernel memory via an out-of-bounds write, potentially escalating privileges or crashing the host. The handler validates fields read directly out of the user-shared, mmap'd io_uring SQE, so a racing thread can enlarge request_len after the bound check but before copy_from_user(), overflowing the fixed-size scmd->cmnd buffer inside the kernel. Affected are kernels built with bsg io_uring passthrough support (EUVD lists Linux 7.1 in the affected commit range), with exploitation requiring local access to a /dev/bsg device node plus a multi-threaded racer that wins a narrow check-to-use window; the vendor rates it 7.8 while the independent assessment agrees it is a genuinely serious bug but raises attack complexity to AC:H because success is probabilistic per attempt. No publicly available exploit code was identified at the time of analysis, and no KEV listing was provided.
An out-of-bounds write in the Linux kernel's megaraid_sas driver (megasas_make_prp_nvme) lets a locally present user submitting large block I/O to an NVMe drive behind a Broadcom/LSI MegaRAID controller overflow the cmd->sg_frame DMA pool buffer, corrupting such a list to run up to a full page past its allocation. The flaw is only reachable on Linux 6.17 and later, after block commit 9b8b84879d4a raised the default maximum transfer size to 4 MiB, and on drives whose firmware reports a large MDTS so max_hw_sectors is not clamped; systems with small-MDTS drives never hit the condition. Per the independent assessment, the vendor score of 7.8 overstates real-world risk (assessed AV:L/AC:H/PR:L with C:N/I:L/A:H): exploitation requires local access plus specific storage hardware, is not remotely reachable, and no public exploit was identified at time of analysis. Consequences range from a kernel page fault and crash (availability) to silent corruption of a neighbouring in-flight command's PRP list when the following page happens to be mapped.
Linux kernel pm8001 SAS/SATA HBA driver contains an error-path cleanup bug that can leave MSI-X interrupt handlers installed when request_irq() fails during driver initialization, because the rollback loop uses the failing index instead of the previously registered vector index. Systems with a PMC-Sierra/Adaptec 8001-series controller bound to the pm8001/pm80xx driver and kernel versions from 4.11 up to the fixed releases are affected. The issue is not attacker-reachable-it requires a non-attacker-influenced interrupt allocation failure-so independent assessment rates it low-impact availability-only (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L), and no public exploit has been identified at time of analysis.
A race condition in the Linux kernel futex priority-inheritance requeue path (FUTEX_CMP_REQUEUE_PI) allows a waiter's stack-allocated futex_q to be freed while a concurrent requeue task is still about to call rcuwait_wake_up() on it, producing a slab-out-of-bounds use-after-free that typically surfaces as a KASAN report and kernel crash. Only kernels built with PREEMPT_RT reach the affected code path; on such systems any local, unprivileged process can trigger it, but exploitation requires winning a narrow, non-deterministic timing window in which an early wakeup (futex timeout or delivered signal) races the concurrent PI requeue. No confirmed active exploitation and no public exploit code had been identified at time of analysis, and the practical outcome is denial of service rather than code execution or data disclosure.
Linux kernel builds with HID-BPF support (CONFIG_HID_BPF) can be crashed by a race that double-releases a HID device reference: a BPF map delete invoking hid_bpf_unreg() (no BPF_F_LINK) can run concurrently with device destruction via hid_destroy_device(), so both paths call hid_put_device() on the same registration reference and the struct hid_device is freed while teardown is still executing inside hid_destroy_device(). The attacker must already hold the local privileges required to attach a HID-BPF struct_ops program (CAP_BPF/CAP_SYS_ADMIN, effectively root) and win a narrow timing window, so the independent assessment is materially lower than the vendor's 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and rates it as a crash-class fault (A:H, I:L, C:N) rather than code execution or data disclosure. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; patched stable releases (6.12.110, 6.18.51, 7.2.5, with a 7.3-rc2 fix) are available from the vendor.
Out-of-bounds reads and writes in the Linux kernel's hid-rmi driver let a physically attached HID device that advertises the Synaptics RMI report IDs (RMI_DEVICE) leak kernel heap memory and corrupt adjacent slab objects during probe, with the stolen bytes surfaced to any local user through a mode-0444 sysfs attribute. Unpatched kernels from 3.16 onward are affected up to the listed fixed releases, which include 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc2; no public exploit code has been identified at time of analysis. The vendor CVSS of 8.8 (AV:A/PR:N/UI:N) overstates real-world risk - our assessment is AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H - because an attacker must supply the device locally (or already be root to force a bind via new_id) and the code paths only run during probe, though the confidentiality impact is real since the leaked register data is exposed to unprivileged userspace and echoed back to the device itself.
An out-of-bounds read in the Linux kernel's Wacom Bluetooth HID driver (wacom_intuos_pro2_bt_irq) allows an attacker in Bluetooth range who controls, spoofs, or merely operates a malfunctioning paired peripheral advertising a Wacom Intuos Pro/Intuos BT VID/PID to make the kernel parse a report shorter than the branch's fixed offsets, reading past the end of the received buffer. Because the driver force-registers pen, pad and touch input nodes for the matched device type via wacom_setup_device_quirks(), the leaked bytes are forwarded to userspace through evdev (MSC_SERIAL, ABS_MISC, ABS_WHEEL), giving a concrete confidentiality channel in addition to the immediate availability impact of a kernel OOB access on short descriptors. The reported CVSS is 8.1 (AV:A/AC:L/PR:N/UI:N), while our independent assessment rates it CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H - still adjacent and unauthenticated from a credential standpoint, but requiring the victim to pair/trust the hostile peripheral and, for any real confidentiality payoff, a local process consuming the evdev stream. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (not CISA KEV); vendor patches are available in current stable trees.
A use-after-free race condition in the Linux kernel's device-mapper (dm) subsystem can be triggered when two concurrent DM_TABLE_LOAD ioctls are issued against the same device and one succeeds while the other fails, allowing the unlocked walk of md->table_devices in dm_setup_md_queue to dereference memory already freed by dm_table_destroy. The vendor scored this 7.8, but our independent assessment places it at CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H - exploitation requires local, root-equivalent CAP_SYS_ADMIN access to /dev/mapper/control and winning a narrow, non-deterministic timing window, so the realistic worst case is a host crash or denial of service rather than code execution or data disclosure. No public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV; vendor patches are available for the 6.1, 6.6, 6.12, 6.18 and 7.2 stable branches.
Local attackers holding CAP_SYS_ADMIN can crash or destabilize the Linux kernel by racing the device-mapper resume ioctl against a concurrent device removal on the same mapped device, so the table is torn down in __dm_destroy without the postsuspend callback the dm targets depend on. The most concrete consequence documented is a use-after-free in the dm-integrity target, whose reboot notifier is left registered when postsuspend is skipped, while other targets may simply misbehave; the independent assessment rates this as a privilege-gated, non-deterministic denial-of-service rather than code execution or data disclosure, materially below the vendor's 7.8 HIGH score. No public exploit code has been identified at time of analysis, and the flaw is not known to be actively exploited.
A functional regression introduced in the Linux kernel's dma-direct allocator by commit 5b138c534fda causes dma_direct_alloc_from_pool() to hand back a CPU address where its caller dma_direct_alloc_pages() expects a struct page pointer, so that path dereferences an address as page metadata and can corrupt state or crash the kernel. Only kernels built with the atomic DMA coherent pool (CONFIG_DMA_COHERENT_POOL) and configurations that route coherent allocations through the atomic pool - typically GFP_ATOMIC or restricted/non-coherent DMA device paths - are exposed, and the bug is reachable only by local kernel/driver DMA activity with low privileges, not over a network. No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV entry); severity should be read as the low-CIA/availability-heavy impact assessed locally (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) rather than the higher network-adjacent score carried in some feeds.
Denial of service in the Linux kernel's fsl-edma DMA engine driver lets a local user with write access to tracefs event-injection files crash the system by causing the fsl_edma trace event handler to dereference a stale struct fsl_edma_engine pointer. Affected systems are those running NXP/Freescale eDMA hardware (for example i.MX or Layerscape) with kernel tracing enabled; the independent assessment rates this as a local DoS requiring root/CAP_SYS_ADMIN (assessed CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H), which is narrower than the vendor's 7.8 score. A local trigger is described in the upstream fix, so publicly available exploit code exists, but there is no CISA KEV entry indicating active exploitation.
Improper freeing of a kernel heap buffer in the Linux kernel's cpuidle device-tree idle power-domain support (dt_idle_genpd) can crash affected systems when a device-tree idle power domain is torn down. Kernels built with CONFIG_DT_IDLE_GENPD and instantiated DT idle power domains - introduced by commit 9d976d6721df (present since Linux 5.18) and fixed in stable releases 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5/7.3-rc2 - are affected, which in practice means ARM/embedded PSCI-style platforms whose firmware provides cpuidle power-domain nodes. Triggering requires local privileged or boot-time influence over device-tree content or the ability to force genpd teardown/probe failure, so this is not remotely reachable and no public exploit has been identified at time of analysis; the practical impact is a kernel crash rather than code execution or data disclosure, despite the 8.4 base score reported by NVD-style scoring (our own assessment is AV:L/AC:H/PR:H with C:N/I:N/A:H).
A use-after-free race in the Linux kernel CephFS client allows a local process to crash the kernel while opening a file on an in-kernel CephFS mount, with a secondary integrity impact on the access-check result. The bug lives in ceph_mds_check_access(), which walks the mdsc->s_cap_auths array without holding mdsc->mutex, so a concurrent MDS session OPEN (reopen) that replaces and frees that array under the mutex can free the strings mid-traversal - the oops trace shows ceph_mds_check_access reached via ceph_atomic_open and do_sys_openat2. Affected systems are Linux 6.10 and later (where the s_cap_auths access-checking code exists) that mount CephFS with the in-kernel client; exploitation is local-only, requires a narrow timing window (AV:L/AC:H/PR:L per our assessment), and no public exploit code has been identified at time of analysis. The vendor-assigned CVSS of 9.8 (AV:N/AC:L/PR:N) is severely inflated relative to the described local race.
A use-after-free race condition in the Linux kernel kprobes subsystem (CVE-2026-89988) lets a highly privileged local actor corrupt kernel memory by racing a blacklist traversal against a concurrent kernel module unload. Specifically, __within_kprobe_blacklist() walks kprobe_blacklist without holding kprobe_mutex, while kprobe_remove_area_blacklist() unlinks and immediately kfree()s those same entries when a module is unloaded, so a traversal that lands in the race window dereferences freed memory. The upstream fix converts the list to RCU (guard(rcu)(), list_for_each_entry_rcu(), list_add_tail_rcu(), list_del_rcu(), kfree_rcu()); it is not known to be exploited and no public exploit code was identified at time of analysis, and EPSS/KEV data are absent. Our independent assessment rates this materially lower than the published CVSS 7.8: it requires local access with the ability to register kprobes (root / CAP_SYS_ADMIN / CAP_SYS_MODULE or the debugfs kprobe interface) plus concurrent module load/unload churn, and the timing window is narrow (AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H, moderate, ~4.7).
A context-inappropriate allocation in the Linux kernel's weighted-interleave memory policy path causes a sleeping (GFP_KERNEL) allocation to be performed while executing in atomic/RCU context. The bug exists only in kernels that provide the MPOL_WEIGHTED_INTERLEAVE mempolicy, introduced in Linux 6.9, and is triggered when an authenticated local user has that policy set on the current task while an rhashtable bucket-table allocation rehashes under rcu_read_lock() with GFP_ATOMIC and falls back to vmalloc (__vmalloc_node_range_noprof → vm_area_alloc_pages → alloc_pages_bulk_mempolicy → alloc_pages_bulk_weighted_interleave), which then hardcodes GFP_KERNEL for its temporary weights array. The observable impact is a might_alloc()/might_sleep() splat - most visible with CONFIG_DEBUG_ATOMIC_SLEEP enabled - with no confidentiality or integrity consequence and at most a minor availability effect; the window is timing- and workload-dependent and not directly attacker-controlled, and no public exploit has been identified at time of analysis. The vendor's assigned CVSS of 7.8 is substantially higher than the assessed real-world risk, which our analysis rates as low (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).
Cross-node folio migration in the Linux kernel 7.1 memory cgroup controller can leave a folio's objcg pointing at a different node than the LRU list the folio actually belongs to, so memcg reparenting resolves the wrong lruvec and takes the wrong lru_lock, corrupting memory-cgroup accounting and risking kernel failure (assessed availability impact High, integrity Low, confidentiality None). Exposure is narrow: it requires the memory controller active (default in modern container/systemd deployments), genuinely multi-node NUMA hardware, local authenticated access (CVSS vector PR:L) to trigger cross-node migration, and a race with memcg_reparent_objcgs() during cgroup offline in the non-atomic window between objcg and LRU-splicing iterations; single-node systems and kernels before 7.1 are unaffected. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; vendor fixes are 7.2.5 and 7.3-rc1, so the vendor score of 7.8 (AV:L/AC:L/.../C:H/I:H/A:H) materially overstates real-world risk relative to the assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H.
Uninitialized spinlock use in the Linux kernel's ALSA 'harmony' driver (HP PA-RISC CS4215 sound hardware) can crash the system during driver initialization, because snd_harmony_create() calls request_irq() before h->lock and h->mixer_lock are initialized and a pending interrupt can fire the handler against garbage lock state. Only systems with this legacy driver present and probing on real or emulated PA-RISC hardware are exposed, and triggering it requires a narrow hardware timing window during boot or root-privileged module load, so there is no public exploit identified at time of analysis and independent assessment rates real-world risk as low despite the vendor's 8.4 (HIGH) score - the assessed impact is availability-only (local denial of service/crash) under a privileged, high-complexity precondition. Vendor patches have been published as upstream commits and are shipped in the stable releases listed below.
A race condition in the Linux kernel ALSA PCM (sound) subsystem allows a local, authenticated user with access to a sound device node to trigger conflicting PCM state transitions - specifically, an atomic trigger-start racing a non-atomic hw_params, hw_free, or prepare operation on the same stream. The realistic outcome is internal state inconsistency and a kernel ODEBUG warning (as reported by syzkaller), not memory corruption or privilege escalation; the distro-assigned CVSS of 7.8 is substantially overstated relative to the assessed vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), which reflects low availability impact only. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so exploitation requires winning a tight, non-deterministic timing race from an already-privileged local position.
Double free in the Linux kernel's NVMe-over-Fabrics Fibre Channel (nvme-fc) transport lets a privileged local user corrupt kernel memory when an nvme-fc controller creation attempt fails. The bug lives on an error path: nvme_fc_init_ctrl() jumps to out_put_ctrl: when nvme_add_ctrl() fails (reached when dev_set_name() cannot allocate memory), bypassing the pointer clear that nvme_fc_ctrl_free() relies on, so the transport frees the fabrics options and nvmf_create_ctrl() frees them a second time - KASAN reports a slab-use-after-free in nvmf_free_options(). Introduced by commit 1a9e218195a5 and present in kernels from 6.11 through the fixed stable releases, exploitation requires root/CAP_SYS_ADMIN, the non-default nvme-fc transport, and a narrow allocation-failure window (memory pressure or kernel fault injection); no public exploit identified at time of analysis, and the assessment rates availability impact high with confidentiality and integrity impact none.
Denial of service in the Linux kernel's NVMe-over-TCP (nvme-tcp) host driver, where nvme_tcp_handle_c2h_data() accepts a controller-to-host data PDU for a command that did not request a read; the receive path then hits WARN_ON_ONCE(i->data_source) inside _copy_to_iter(), returns -EFAULT, and resets the controller. The impacted component is the initiator side of the NVMe-oF TCP transport, so hosts are only at risk when they attach to a malicious or compromised NVMe-oF TCP target that can dictate PDU sequencing; there is no public exploit identified at time of analysis, and the practical severity is modest because the trigger requires control of the storage controller the host talks to (inverted trust model). Impact is normally limited to a failed command plus a controller reset, but on hosts booted with panic_on_warn the same warning becomes an immediate kernel panic and full system outage, which is the key amplifying condition behind the assigned A:H rating.
A race condition in the Linux kernel's NVMe-over-Fabrics target authentication code (nvmet-auth) can leave a queue structure (struct nvmet_sq) freed or reused while the auth_expired_work delayed-work callback is still executing, potentially crashing or corrupting the memory of the target host. Exposure is limited to Linux systems acting as NVMe-oF targets (nvmet) with in-band DH-HMAC-CHAP authentication enabled: an attacker must be positioned on the NVMe-oF fabric (TCP or RDMA), be able to open and tear down authenticated sessions, and win a narrow, non-deterministic timing window during transport teardown, which is why our independent assessment rates the issue well below the vendor's 9.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H) and finds no confidentiality impact despite the 'Information Disclosure' tag. Vendor patches are available in the stable branches (6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc2), and no public exploit or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds write in the Linux kernel's NVMe-over-Fabrics TCP target (nvmet-tcp) allows a network-reachable initiator to write four attacker-controlled bytes past a 128-byte receive buffer by sending a duplicate ICReq PDU after a header digest has been negotiated, corrupting adjacent queue state. The bug is reachable before authentication (CVSS PR:N), and the assessed impact is high availability (target crash or teardown) with a limited integrity effect and no confidentiality impact. Vendor patches exist for all supported stable trees, and no public exploit code or confirmed active exploitation was identified at time of analysis; practical exposure is confined to hosts that actually export an NVMe/TCP target subsystem, typically on port 4420.
Remote, unauthenticated denial of service in the Linux kernel's NVMe-over-TCP target (nvmet-tcp) lets a permitted host wedge the target workqueue by racing an unsolicited H2CData PDU ahead of the target's Ready-to-Transfer message. A write command that takes the R2T path is completed twice, causing a response-list entry to point to itself and, depending on CONFIG_DEBUG_LIST, triggering a kernel BUG or an infinite loop/soft-lockup in the nvmet_tcp workqueue. Only hosts configured as NVMe/TCP targets (particularly subsystems using allow_any_host) are affected; no public exploit code has been identified at time of analysis, and the assessed CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
An out-of-bounds write in the Linux kernel's device-memory migration helpers (mm/migrate_device) allows a local user who holds a file descriptor to a ZONE_DEVICE/HMM-capable device to corrupt kernel memory. When a compound (transparent huge) folio is migrated into device memory and its page-granular span extends past the end of the caller-supplied npages PFN array, migrate_device_range() and migrate_device_pfns() clear folio entries past the array boundary; the path is exercised in practice by dmirror_fops_release() on /dev/hmm_dmirror0 and by GPU shared-virtual-memory drivers such as nouveau or amdgpu SVM. Exploitation is local only and conditional, requiring a device-memory migration-capable kernel build and a specific huge-page-versus-range boundary condition (assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, integrity and availability impact with no confidentiality impact); no public exploit identified at time of analysis.
Out-of-bounds write in the Linux kernel's nvdimm BTT (Block Translation Table) driver allows a privileged local attacker who can supply a crafted or foreign BTT arena to corrupt kernel memory, primarily degrading availability and potentially altering data. The flaw is triggered when the BTT info block's unvalidated nfree field is set below the host's per-lane count (ND_MAX_LANES), so the I/O path indexes freelist[]/rtt[] arrays past their allocations; exploitation requires local root/CAP_SYS_ADMIN or physical control over the persistent-memory medium being probed, making it a low-real-risk issue despite a high base score. There is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); EPSS data was not supplied.
Incorrect PFN bookkeeping in the Linux kernel's PowerPC compound vmemmap population path (vmemmap_populate_compound_pages) causes the kernel to compute the wrong pfn_offset and therefore make the head/tail struct-page mapping decision for the wrong position within a compound page, which can corrupt vmemmap contents or crash the system when PowerPC systems exercise compound-page vmemmap optimization (ZONE_DEVICE / device-DAX / persistent memory or memory-hotplug configurations). This is a deterministic setup- or boot-time arithmetic miscalculation rather than an attacker-controlled primitive: the vendor CVSS of 7.8 assumes local, low-privilege access with high confidentiality and integrity impact, but an independent re-assessment scores it CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H, noting the vendor vector appears over-scored because triggering the mis-decision requires high privileges to drive memory hotplug/device configuration, depends on specific compound-page population and alignment conditions, and has no remote or unauthenticated vector. No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is limited to PowerPC (PPC) kernels, and vendor-released fixes are available in the 6.6.157, 6.12.110, 6.18.51, 7.2.5, and 7.3-rc1 stable/mainline trees.
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with host-side privilege to corrupt kernel state by attaching a second vfio-ap mediated device to a KVM instance that already owns one. On the resulting -EPERM error path, vfio_ap_mdev_set_kvm() fails to restore kvm->arch.crypto.pqap_hook, leaving it pointing at an mdev that is never tracked by matrix_mdev->kvm; when that mdev is later freed, a guest-executed PQAP instruction dereferences the stale hook through pqap_hook_rwsem and triggers the use-after-free. Exploitation requires an IBM Z/s390 host running KVM with vfio-ap enabled but is not remotely reachable, needs authenticated local privilege to configure mediated devices, and depends on error-path plus free-then-execute sequencing; no public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available in the stable trees.
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access when a privileged host administrator unplugs a control domain from a matrix mdev: vfio_ap_mdev_cfg_remove clears the wrong bit set with bitmap_andnot instead of intersecting with bitmap_and on the mdev's adm bitmap. The practical result is that a KVM guest on IBM Z hardware configured for AP (Adjunct Processor) passthrough retains access to control domains the host intended to remove, a residual-access/state-desynchronization condition rather than remote code execution, reached only when a host admin performs an explicit control-domain removal (CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-supplied 8.8 score (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) materially overstates real-world risk given that exploitation is confined to the rare s390 crypto-passthrough deployment mode and requires a trusted privileged reconfiguration action.
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the vfio-ap mediated-device driver: when the last AP adapter, domain, or control domain is removed from the host's AP configuration, the shadow APCB is cleared but the bitmap_andnot() return value is false for an empty result, so the do_hotplug flag never gets set and the guest's APCB is never refreshed. Only s390 hosts with CEX crypto adapters configured for guest passthrough are affected, exploitation is local and requires privileged host management access to modify the AP configuration, and no public exploit code has been identified at time of analysis. The practical consequence is a crypto-resource isolation failure in which the guest passively retains access to AP devices the administrator believes were unplugged, not memory corruption or code execution.
Out-of-bounds access in the Linux kernel MTD AFS (ARM Flash Structure) v2 partition parser lets crafted flash contents drive the image-information offset and region count beyond the bounds of the local image-info array, producing a kernel memory-safety fault during partition scanning. The code path is only reachable on platforms that enable and scan AFS v2 partitions, and per the independent assessment exploitation requires a local actor with high privileges (PR:H) - root or CAP_SYS_ADMIN write access to the raw MTD device, or physical replacement/tampering of the flash chip - with the malicious data consumed when the kernel parses the partition table at boot or device attach. It is deterministic once the crafted flash is in place, and no public exploit identified at time of analysis; the CVE carries an NVD base score of 8.0 while cross-checked analysis places the practical risk substantially lower because there is no remote or unprivileged path. Vendor-released fixes are available in the stable trees listed below.
A use-after-free in the Linux kernel's batman-adv (B.A.T.M.A.N. advanced) mesh networking module lets an attacker on the adjacent mesh trigger a kernel crash by exploiting stale receive-device metadata on reassembled fragments. When batman-adv merges buffered fragments it reuses the skb from the highest-numbered fragment; if the hard interface that carried that fragment is torn down before the fragment chain completes, the merged skb re-enters the receive path holding a freed skb->dev pointer, and the DAT and bridge loop avoidance handlers dereference it when computing the ARP header length. The assessed impact is availability only (kernel crash/DoS) with at most limited integrity effects, requiring a narrow race between fragment buffering and administrative interface removal; no public exploit code has been identified, no KEV listing exists, and exploitation is limited to the adjacent mesh segment (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H assessed; NVD published a higher 8.8 vector that this analysis does not corroborate).
An out-of-bounds read in the Amlogic Meson GXBB clock controller driver causes a kernel global-out-of-bounds report (KASAN: read of size 8 in gxbb_32k_clk_parents) during clock registration at boot on GXBB-based boards such as the WeTek Hub. The defect comes from a mux parent count that was left hard-coded after a stale parent entry was removed, so the driver walks one slot past the end of its parent array; affected code shipped in stable kernels including 5.4.292+, 5.10.236-5.10.269, 5.15.180-5.15.220, 6.1.134-6.1.187, 6.6.87-6.6.156, 6.12.23-6.12.109, 6.13.11-6.13.x, 6.14.2-6.14.x and the 6.15 mainline series, and is fixed in newer stable releases (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5, 7.3-rc1). There is no public exploit identified at time of analysis and no CISA KEV listing, and nothing more than a local unauthenticated vector exists in the CVSS data (AV:L, PR:N); our independent assessment rates it CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, far below the vendor's 8.0 vector, because the read is triggered solely by the driver's own probe and is not controllable by any user, network input, or configuration toggle.
A missing error check in the Linux kernel's Loongson ASoC sound-card ACPI probe path (loongson_card_parse_acpi) leaves the pointer returned by device_property_read_string() for the 'codec-dai-name' property uninitialized when that property is absent or invalid, and the stale pointer is dereferenced later during driver binding. Only LoongArch/Loongson platforms whose ACPI firmware omits or malforms codec-dai-name are affected, and reaching the bug requires the ability to supply or modify that firmware description - it is not reachable over the network and not triggerable by an unprivileged local user on a default, correctly-described platform. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor's CVSS 8.4 rating substantially overstates the assessed risk (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H), and the vendor vector is also internally inconsistent because it computes to 7.8 rather than 8.4.
A local use-after-free in the Linux kernel's Industrial I/O (IIO) subsystem can crash or corrupt the kernel when an anonymous IIO buffer handle is released while its underlying IIO device is being torn down at the same time. Only kernels built with the anonymous/DMABUF buffer interface introduced in 6.11 are affected, and the vendor-scored 7.8 severity is not supported by the evidence: exploitation requires local low-privileged access (CVSS PR:L), a narrow race with driver unbind or hot-unplug (AC:H), and results in denial of service (kernel memory corruption/crash) rather than the high confidentiality and integrity impact the vendor vector claims. Patches are available in the stable tree (6.12.110, 6.18.51, 7.2.5, and 7.3-rc1); no confirmed active exploitation (CISA KEV) and no public exploit code were identified at time of analysis.
A race-condition use-after-free in the Linux kernel's IIO (Industrial I/O) buffer DMA-fence implementation allows a local attacker with access to an IIO device exposing the DMABUF buffer interface to corrupt kernel memory by racing the fence's teardown against lockless RCU readers - the custom release path calls kfree() rather than deferring the free through RCU or the standard dma_fence_free() helper. The flaw affects kernels that include the IIO DMABUF buffer support introduced in 6.11 and was fixed in 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1; exploitation requires a vulnerable IIO DMABUF-capable device, a build with that support enabled, and a timing-dependent race window, so it is local-only and not deterministic. Per independent assessment the realistic impact is availability and limited integrity loss (AC:H, C:N/I:L/A:H) rather than the confidentiality breach suggested by the higher vendor-published score, and no public exploit code has been identified at time of analysis.
Use-after-free in the Linux kernel's IIO buffer DMABUF path where an iio_dma_fence can outlive the iio_dmabuf_priv structure that holds its embedded lock, so a fence signal or release callback can touch a freed lock object. Affected kernels are Linux 6.11 through the fixed releases 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and exploitation requires local access to a host whose hardware/driver exposes the IIO DMABUF buffer interface with permission to open the IIO device node (CVSS PR:L, no UI). The vendor advisory lists a patch, and no public exploit or CISA KEV entry was identified at time of analysis; our independent assessment rates this Medium (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) because the race window is timing-sensitive and the affected surface is driver-specific rather than universal, which is noticeably lower than the vendor-supplied 7.8 vector.
Use-after-free in the Linux kernel's IIO atlas-sensor driver (Atlas Scientific chemical sensors) is reachable when an IIO buffer is enabled and the driver is torn down: the devm-managed data-ready IRQ keeps queueing an irq_work that calls iio_trigger_poll(data->trig), and free_irq() during the devres unwind after atlas_remove() never flushes that pending work, so atlas_work_handler() can dereference an already-freed trigger/indio_dev via container_of(). The driver has existed since Linux 4.8 and is only present on systems with real Atlas Scientific I2C sensor hardware attached; exploitation requires authenticated local access (typically root privileges to unbind the device or unload the module), with an enabled buffer, and it is constrained by a narrow race-timing window - the assessed impact is low integrity and high availability (denial of service / memory corruption on teardown) with no confidentiality impact. No public exploit identified at time of analysis, and the flaw was closed upstream by calling iio_trigger_poll_nested() directly from the threaded handler so free_irq() drains it, with fixes shipped in 6.6.157, 6.12.110, 6.18.51 and 7.2.5.
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on x86 Intel VMX hosts, because vpid02 is not flushed on its first use after a VPID is recycled following an L1 guest's VMXOFF/VMXON cycle. Exploitation requires an attacker who already controls an L1 guest on a host running KVM with nested virtualization enabled (kvm_intel nested=1) where L1 uses VPID for its L2 guests, and success depends on KVM reusing a vpid02 value that still has TLB entries resident on the physical CPU, making the outcome timing- and reuse-dependent rather than deterministic. No public exploit has been identified at time of analysis, and our independent assessment rates the realistic impact well below the vendor's CVSS 8.8 - limited confidentiality and integrity loss with high availability impact under local, high-complexity preconditions (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H).
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. The independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - local hypervisor context, non-default configuration, no confidentiality impact, limited integrity and availability impact - and notes it is not exploitable against default (non-nested) KVM deployments; no public exploit code or confirmed active exploitation has been identified at time of analysis.
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM executes the L1 guest's INVVPID on whichever pCPU is currently active rather than on the pCPU where L2 last ran. When L1 migrates to another CPU, issues INVVPID, and then migrates back to the original CPU to resume L2, the stale VPID mappings on that original pCPU are never invalidated and vmx_vcpu_load_vmcs() does not request a KVM_REQ_TLB_FLUSH because vmcs02 never ran on a different pCPU. Affected are x86 hosts with non-default nested virtualization enabled and a malicious or buggy L1 guest controlling an L2 guest; exploitation requires local access to an L1 vCPU (PR:L) and a narrow cross-CPU scheduling/migration race, no public exploit code has been identified at time of analysis, and CISA KEV does not list this issue. The judged impact is primarily TLB corruption and nested-guest instability rather than a reliable code-execution or data-exfiltration primitive, consistent with an assessed vector of AV:L/AC:H/PR:L/S:C/C:L/I:L/A:H.
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through 6.18.50 and 7.x before 7.2.5 that are built with CONFIG_KVM_MMU_LOCKLESS_AGING=y. A local user able to run or drive a KVM guest (PR:L, no user interaction) can race the lock-elision window so that a writer populates a KVM_RMAP_MANY rmap and later frees its pte_list_desc chain while the lockless aging walk is still traversing it, yielding memory corruption of kernel slab memory; the race is timing-dependent (AC:H) and is driven by host memory reclaim rather than attacker-controlled scheduling, so exploitation is opportunistic rather than deterministic. No proof-of-concept or public exploit code has been identified at time of analysis and there is no evidence of active exploitation. Vendor scoring is 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), while independent assessment rates it 6.3 with AC:H and no confidentiality impact, reflecting the narrow, reclaim-triggered race window; it is a local privilege/DoS-class memory-safety bug, not a remote code execution issue despite the 'RCE' tag on the record.
An integer overflow in KVM's x86 Hyper-V synthetic timer emulation (stimer_start(), which computes a 100ns-tick deadline using ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))) allows a guest or userspace VMM to program a STIMERi deadline that wraps into the past, causing the vCPU to spin through an immediate hrtimer re-arm / KVM_REQ_HV_STIMER request cycle without ever disabling the timer. The result is a host CPU livelock that starves RCU grace-period kthreads and produces the RCU stall and eventual OOM condition reported by syzkaller. Exploitation requires a KVM x86 host running a guest with Hyper-V enlightenments and SynIC synthetic timers exposed, and control over the guest's WRMSR (HV_X64_MSR_STIMERi_CONFIG/COUNT) or KVM_SET_MSRS writes; the assessed vector is local, PR:L, availability-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, 7.1), with no public exploit identified at time of analysis and no CISA KEV listing.
A use-after-free race condition in the Linux kernel's s390 KVM guest-debug watchpoint code lets a local user who can control an IBM Z guest VM read or corrupt freed kernel memory. When a hardware watchpoint is imported via the KVM_SET_GUEST_DEBUG path, __import_wp_info() backs up guest memory with read_guest_abs() without holding kvm->srcu, so a concurrent memslot update can free the memslots array mid-read. Exploitation is s390-specific, requires local privileges over the VM/VMM (authenticated, PR:L per the assessed vector) and a narrow timing window, so reliability is limited; no public exploit code and no confirmed active exploitation were identified at time of analysis, and patch data indicates the vendor has released fixes.
Memory corruption on IBM Z (s390) KVM hosts running the Linux kernel is triggered when a channel-subsystem damage machine check (the CK bit) is reinjected into a guest, causing the host kernel to kfree() a stack variable. Exploitation requires an authenticated local actor with existing privileges on an s390 host that runs KVM guests (CVSS AV:L/PR:L) and depends on a hardware/host error condition that cannot be summoned on demand, which is reflected in the assessed AC:H and a scope-changed impact profile of low integrity and high availability impact rather than full host compromise. Vendor-released patches exist (stable 6.18.51, 7.2.5 and 7.3-rc1/mainline commits); no public exploit code and no confirmed active exploitation were identified at time of analysis.
A race condition in the Linux kernel's KVM s390 (IBM Z) keyop path lets a local user who already holds a KVM VM file descriptor cause gmap->asce to be read without the mmu_lock, potentially using a stale address-space-control element and corrupting memory. Exploitation requires s390 hardware, VM-fd access, and issuing KVM_S390_KEYOP concurrently with KVM_S390_VM_MEM_LIMIT_SIZE so that keyop reads asce while gmap_set_limit() mutates it under the write lock; it is timing-dependent, not remotely reachable, and no public exploit has been identified at time of analysis. The upstream fix has been merged and shipped in stable Linux 7.2.5 and 7.3-rc1, though an independent assessment rates real-world impact lower than the 7.8 base score by downgrading attack complexity to High and scope/confidentiality impact to None/low integrity, high availability.
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip an invalidation when the range ends at the last page or block of the TTBR1 VA space, because the exclusive end computation (base + size) wraps to zero. The faulty logic was introduced in Linux 6.16 and is fixed in 6.18.51, 7.2.5 and 7.3-rc1; hosts running unpatched kernels are exposed where a guest vCPU can drive trapped TLB-by-VA invalidations, while the IPA-invalidation path never suffered the rollover. The assessed vector is local (AV:L) with low privileges (PR:L) and high attack complexity (AC:H) because of the narrow address-layout precondition, with scope change and high availability impact; no public exploit code and no confirmed active exploitation (no CISA KEV entry) have been identified, and the provided reference CVSS of 9.3 overstates the practical risk relative to that assessment.
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed for a page-table mapping that another vCPU has just invalidated, so a guest can keep using a translation the host believes is gone, corrupting host state and potentially crashing the host. The flaw only affects arm64 hosts running KVM with nested virtualization (FEAT_NV2 / VNCR fixmap) enabled where an attacker already controls a guest with at least two concurrently executing vCPUs, and exploitation hinges on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another (one vCPU rewriting S1 page tables and issuing TLBI S1E2 while the other is mid-walk). Because the path is local-only and nested virtualization on arm64 is rarely deployed, the independent assessment rates the issue well below the vendor's CVSS 9.3 (assessed AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - high availability impact, low integrity impact, no confidentiality impact); no public exploit identified at time of analysis, and vendor patches are available in Linux 7.2.5, 6.18.51 and 7.3-rc1.
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations for an L1-supplied VNCR page in L0, allowing a guest with control of an L1 vCPU on an arm64 host to cross the guest-to-host boundary in a timing-sensitive way. Affected systems are those running kernel 6.16 or later with arm64 nested virtualization (FEAT_NV2 / VNCR page support) enabled and exposed to a guest; the flaw is a guest-to-host (L1-to-L0) issue, so exploitation requires guest-vCPU privileges and is local to the host, which contradicts the vendor's PR:N vector. Vendor-released patches exist in Linux 6.18.52, 7.2.5, and 7.3-rc1, and no public exploit code has been identified at time of analysis; the vendor's CVSS of 9.3 substantially overstates real-world risk given that nested virtualization is off by default and deployed on only a small subset of arm64 KVM hosts, and the missed-invalidation window is opportunistic and mapping-state dependent rather than deterministic.
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range because the decode_range_tlbi() helper omitted the required virtual-address sign-extension when it was reused for stage-1 TLBI handling, and the same helper can overflow physical-address bits when invoked for stage-2 invalidation. Only arm64 hosts running KVM are affected, and the attacker must already control a guest VM/vCPU able to issue range-based TLBI operations (low-privilege guest context, no user interaction, no network reachability); kernels from the 6.16 introduction through the fixes in 6.18.51, 7.2.5 and 7.3-rc1 are in scope. Exploitation results in stale or incorrectly scoped TLB entries on the host, with the assessed impact being availability loss (A:H) plus limited integrity impact (I:L) and no confidentiality impact; no public exploit identified at time of analysis.
A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a locally authenticated guest with vCPU-level access to trigger a dangling-pointer dereference against host kernel memory. The flaw requires an arm64 KVM host configured with GICv3 LPI/ITS support, where a concurrent irqfd cached-injection plus a guest ITS DISCARD can free an LPI that the pending-table save loop still holds via a stale xarray iterator pointer; the practical outcome is a host-side crash/denial of service with limited integrity impact rather than a clean, reliable privilege escalation, and exploitation depends on a tight timing window (assessed AV:L/AC:H/PR:L, S:C, C:N/I:L/A:H). Vendor patches are available in Linux 6.18.51, 7.2.5, and 7.3-rc1; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Host denial of service (with potential low integrity impact) in the Linux kernel's KVM/arm64 hypervisor allows a local attacker with guest execution privileges to trigger a TLB invalidation range overflow, corrupting hypervisor state. The flaw affects kernels approximately from 6.16 until the fixes in 6.18.51, 7.2.5, and 7.3-rc1, and requires the guest to issue TLB Invalidation by Range operations with an attacker-chosen virtual address. No public exploit code is identified at time of analysis.
Uninitialized stack memory in the Linux kernel's LoongArch KVM DMSINTC interrupt-injection path can let a local user who is able to create or control a KVM virtual machine - or code running inside a guest - have non-deterministic stack contents consumed while injecting a dynamic message-signaled interrupt. The vendor rates this 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), while our independent assessment keeps the local, low-privilege, scope-changing profile but lowers the impact components to C:L/I:L/A:L because the leaked data is not reliably attacker-controlled; the affected surface is limited to LoongArch hosts with KVM enabled and DMSINTC in use. Vendor fixes are available as upstream stable commits, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling KVM_MEM_LOG_DIRTY_PAGES for live migration) zeroes the slot's architecture-specific flags, so a slot previously marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can subsequently be mapped with PMD-sized entries; because the mapping path aligns the guest frame number and host page frame number independently, the guest can read or write the wrong host pages, giving a local attacker with access to the KVM VM file descriptor both confidentiality and integrity impact on the host (CVSS 8.8 vendor score, AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The independent assessment rates the attack complexity higher (AC:H) because exploitation requires a misaligned memslot plus a flags-only update, typically during live migration, and does not manifest for a static guest with aligned memslots; only the LoongArch architecture is affected. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV, though the tags classify the outcome as information disclosure and the successful corruption path is a memory-safety violation with high integrity impact.
Incorrect jump-offset calculation in the LoongArch BPF JIT of the Linux kernel can emit wrong tail-call branch targets, causing soft lockups (high availability impact) and, per the assessed vector, limited integrity impact, while confidentiality is unaffected. Affected are LoongArch (Loongson) systems running vulnerable kernel branches including the 6.1.x, 6.6.x, 6.12.x, 6.15.x, 6.16.x and 6.17 lines; exploitation requires local access plus the capability to load eBPF programs into the kernel (CAP_BPF or CAP_SYS_ADMIN, since unprivileged BPF is disabled by default), and only manifests when extra JIT passes occur, so it is not a deterministic single-request trigger. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the assessed severity is lower than the headline 7.8 because the flaw is architecture-specific, capability-gated and condition-dependent; vendor-released patches are available in 6.18.51, 7.2.5 and 7.3-rc1.
LoongArch Linux kernels overflow the fixed-size acpi_package_ids[] array while parsing the ACPI PPTT table, so a system whose firmware or hypervisor advertises more CPU packages (sockets) than the array can hold crashes during topology setup - the concrete case in the description being a LoongArch virt VM configured with one core per socket for up to 256 sockets. Affected builds are those before the fixed 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1 kernels; the flaw is reachable only on LoongArch, and the assessed precondition (per our independent analysis: AV:L/AC:H/PR:H, C:N/I:L/A:H) is control over the guest's ACPI topology rather than an ordinary unprivileged runtime action, with the practical outcome being a boot-time crash and memory corruption rather than remote code execution. No public exploit code was identified at the time of analysis and there is no CISA KEV record, so this is not confirmed as actively exploited; the vendor has released patches and the relevant upstream commits are public.
A race in the LoongArch rethook/kretprobe trampoline allows the per-CPU base register ($r21/$u0) to be restored with a stale value after a probed task is preempted and migrated to a different CPU, causing this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) to hit the wrong CPU's percpu area and ultimately corrupting scheduler and timer state. The result under heavy kretprobe load is scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and in the worst case a CPU parking in the idle loop with its timer never re-armed, i.e. a hard lockup and denial of service. Only LoongArch systems running a preemptible kernel with active kretprobes/rethook are affected, and arming kretprobes normally requires CAP_SYS_ADMIN/CAP_PERFMON (root-equivalent), so this is not reachable by unprivileged local users in default configurations; there is no public exploit identified at time of analysis and no confirmed active exploitation.
A preempt-count underflow in the Linux kernel's LoongArch Kprobes breakpoint handling allows a local, low-privileged user to issue the same break 11 instruction that userspace can generate, driving do_bp() into kprobe_singlestep_handler() with no active probe attached and calling preempt_enable_no_resched() without the matching preempt_disable() that kprobe_breakpoint_handler() would normally have performed. Only LoongArch (loongarch64) kernels with Kprobes enabled are affected-other architectures do not use this break-11 path-and the corrupted preempt state makes in_interrupt() return true until the task reschedules, which causes cgroup_sk_alloc() to attribute new sockets to the root cgroup and can thereby evade a BPF_CGROUP_INET_SOCK_CREATE policy bound to the task's own cgroup. No public exploit code identified at time of analysis and the flaw is not listed in CISA KEV; the vendor CVSS of 7.8 overstates practical severity, since independent assessment limits impact to integrity and availability (Low) with no confidentiality impact and notes the notable security consequence requires a BPF cgroup socket-create policy to be present.
A race condition in the Linux kernel HDMI-CEC core (drivers/media/cec) lets a local user who can open a CEC character device (/dev/cecN) free an in-flight transmit data structure while its delayed work item is still pending, corrupting kernel state and typically crashing the system. Exploitation requires a CEC-capable adapter, permission to the device node, and a signal delivered at a narrow timing window between cancel_delayed_work_sync() and the kthread's schedule_delayed_work(&data->work) in cec_transmit_done_ts() - no public exploit code has been identified at time of analysis, and the impact is a denial of service via the debugobjects 'free active' path rather than information disclosure. Vendor-released patches exist in stable trees (6.12.110, 6.18.51, 7.2.5) and in 7.3-rc1; the affected surface is effectively absent on headless servers and most virtualized deployments without CEC hardware.
An out-of-bounds write in the Linux kernel's HDMI-CEC driver for the Extron DA HD 4K Plus adapter (media: cec: extron-da-hd-4k-plus) lets a malicious or malfunctioning CEC device overflow the fixed-size msg.msg[] buffer, crashing the kernel and potentially corrupting kernel memory. Only hosts that have the extron-da-hd-4k-plus driver built and bound to an actual Extron DA HD 4K Plus CEC adapter are affected, and the malformed CEC message must arrive over the physically or adjacently attached CEC/serial link - there is no remote, over-the-network attack path against a default configuration. No public exploit code or in-the-wild exploitation has been identified at time of analysis, and the vendor's CVSS 8.8 (AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H) materially overstates real-world risk; our independent assessment is AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H, since the hardware is rare, the input channel is adjacent-only, and reliable escalation beyond a kernel crash is not demonstrated.
A race condition in the Linux kernel's HDMI-CEC subsystem (media: cec) lets a local user who can open a CEC adapter character device (/dev/cecN) and register as an exclusive follower race message delivery against follower mode changes or adapter release, reading the follower pointer without the adapter lock and creating a window that can corrupt kernel state or leak data. The assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) confirms this is a local, low-privilege issue requiring an actual CEC-capable adapter and precise timing, not the remote/unauthenticated scenario implied by the vendor's AV:A/PR:N score. No public exploit code and no confirmed active exploitation were identified at time of analysis; vendor patches are available across the maintained stable branches.
A heap out-of-bounds write in the Linux kernel's cx231xx USB video-capture driver allows a local, authenticated user (CVSS PR:L) who can open the device's V4L2 video and VBI nodes to corrupt kernel heap memory by resizing the device-wide frame geometry while a VBI stream is already running. The driver latches the VBI plane size at buffer-allocation time but recomputes the destination offset from the live dev->width and dev->norm on every URB completion, so an attacker can allocate a small VBI plane (small width or the NTSC standard), start VBI streaming, then enlarge dev->width via VIDIOC_S_FMT or switch dev->norm to PAL via VIDIOC_S_STD through the video node - the pre-patch code only checks the video queue (dev->vidq), not the VBI queue (dev->vbiq) - and have the device deliver a field-2 payload, causing cx231xx_do_vbi_copy() to memcpy() past the end of the smaller plane with an attacker-chosen offset and device-controlled contents. Vendor patches exist for Linux 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5 (mainline 7.3-rc1); no public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical impact is bounded by the requirement for physical or emulated cx231xx hardware plus a race against live URB completion (the independent assessment scores this AV:L/AC:H with C:L, below the vendor's 7.8 High).
A use-after-free in the Linux kernel's cx23885 media driver lets a local attacker with low privileges (CVSS PR:L) corrupt or crash the kernel by triggering a race during teardown of a Conexant CX23885-based NetUP DVB conditional-access (CI) device. The NetUP CI work item netup_read_ci_status() can still be pending or executing on the system workqueue when netup_ci_exit() frees the associated netup_ci_state, because the removal path calls free_irq() (which stops new interrupts but does not drain already-queued work) before the CI device is unregistered; the fix inserts cancel_work_sync() before dvb_ca_en50221_release() and kfree(). Practical risk is materially lower than the headline score: our assessment rates this AV:L/AC:H (the upstream vector is AV:L/AC:L) because exploitation requires the specific NetUP CI hardware and feature to be active plus a narrow removal-time race window (module unload, device unbind, or physical hot-unplug), and there is no public exploit identified at time of analysis. Vendor-released patches exist for the affected stable series (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, and 7.2.5/7.3-rc1).
A use-after-free in the Linux kernel's go7007 media driver allows a local user who can open the driver's ALSA capture PCM node to trigger memory corruption by keeping that PCM file open across a device removal or unbind event (for example, a USB unplug). The flaw is a lifetime mismatch: go7007_snd_remove() releases the v4l2_device reference immediately after snd_card_free_when_closed(), even though the ALSA card - and its PCM callbacks reaching struct go7007 through pcm->private_data - can stay alive until the last file is closed, so go7007_snd_hw_free() may run against an already-freed object. Per the independent assessment the vector is local-only (AV:L, PR:L, AC:H) with high availability impact and limited confidentiality/integrity impact, and successful, reliable triggering requires the specific WIS GO7007 hardware to be present and the teardown timing window to be won; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. Vendor-released patches are available in the stable branches listed below.
Use-after-free in the Linux kernel's ov02a10 MIPI CSI-2 sensor driver (media: i2c) can abort or destabilize driver probe on systems that physically include an OmniVision OV02A10 camera together with a firmware/device-tree description that binds that driver. The ov02a10_check_hwcfg() function calls fwnode_handle_put() on the parsed endpoint and then reads the optional 'ovti,mipi-clock-voltage' property through the same stale handle, while also letting the failure code from that optional property overwrite the function's return value, so probe can fail even when nothing else is wrong. Affected code ships from Linux 5.11 onward and is fixed in 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1; no public exploit has been identified at time of analysis, and although the vendor scored this 7.8 (HIGH), real-world risk is LOW because the path is reachable only in kernel probe context on specific sensor hardware and is not a remote or user-controllable trigger.
A teardown-order defect in the Linux kernel's ov7740 i2c camera-sensor driver causes a use-after-destroy and a double-free when the driver is unbound or the OmniVision OV7740 sensor is physically removed, panicking the kernel or otherwise taking the system down. Only systems that ship an OV7740 sensor with the CONFIG_VIDEO_OV7740 driver built or loaded are affected, so exposure is limited to specific embedded/SoC platforms. The flaw is local-only, cannot be triggered by an unprivileged process on a default configuration, and no public exploit identified at time of analysis; the vendor scores it 7.8, whereas our reassessment is lower (AV:L/AC:H/PR:L/UI:N/C:N/I:L/A:H) because the realistic impact is a crash rather than code execution or data disclosure - the accompanying 'Information Disclosure' tag is not supported by the assessed vector.
Double-decrementing the SCP device reference in the Linux kernel's MediaTek MDP3 (mtk-mdp3) media platform driver can free or unbalance a device object that the driver still uses, producing driver instability and potentially a use-after-free on systems that take the fallback SCP lookup path. The flaw is only reachable when scp_get() fails during mdp_probe() so that __get_pdev_by_id() runs; the reference taken by that fallback is dropped immediately, yet scp_put() is later called unconditionally from the probe error path and from mdp_video_device_release(). Exposure is confined to local presence on embedded MediaTek SoC hardware running the affected driver, the triggering scp_get() failure is a non-default condition rather than an attacker-controlled input path, and no public exploit code has been identified at time of analysis. Although NVD scores this 8.4, our independent assessment rates it CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H - high severity but low realistic risk.
The Linux kernel's sunxi-cir driver (Allwinner CIR/IR receiver, media/rc subsystem) fails to unregister the rc device when probe fails after rc_register_device() has already succeeded, leaving the registration and its resources behind. This is a local, low-severity driver lifecycle bug: the assessed vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, since the fault requires a genuine probe failure at IRQ lookup, IRQ request, or hardware initialization - conditions that are not attacker-controllable in a default configuration and generally need local privileged access (forced bind/unbind, resource exhaustion, or device-tree/IRQ faults) to induce. No public exploit code has been identified at time of analysis, and vendor-released fixes exist in stable kernels including 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, and 7.2.5.
Out-of-bounds array reads in the Linux kernel's Rockchip rkvdec stateless HEVC decoder allow a local user who can open the V4L2 mem2m decoder device node to trigger an unsigned integer underflow in short-term reference picture set (RPS) prediction, causing the driver to index far outside the calculated_rps_st_sets array. The flaw is reached by submitting an EXT_SPS_ST_RPS control with the INTER_REF_PIC_SET_PRED flag set and a crafted delta_idx_minus1 value that exceeds the current RPS index; the CVSS vector requires local access with low privileges (PR:L), so no third-party user interaction is needed but the attacker must already hold permissions on the decoder device. Impact is bounded to information disclosure and availability (the assessed vector is AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H), and it is confined to embedded Rockchip ARM platforms where the rkvdec driver is present and loaded; no public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV). The vendor-published CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk because exploitation demands specific hardware, driver availability, and a stateless decode session that raises attack complexity and limits the outcome to a memory read rather than code execution.
A missing error-path teardown in the Linux kernel's rtl2832_sdr SDR driver lets a local attacker with low privileges (PR:L) who can reach the V4L2/SDR device node for an RTL2832U-based USB dongle leak coherent DMA memory and trigger an out-of-bounds read/pass-garbage-pointer condition in USB URB cleanup. The defect only manifests when rtl2832_sdr_start_streaming() fails after allocation - realistically an induced -ENOMEM during alloc_stream_bufs()/alloc_urbs()/submit_urbs() - and is then followed by a second VIDIOC_STREAMON, which over-increments urbs_initialized past MAX_BULK_BUFS and causes rtl2832_sdr_free_urbs() to index beyond dev->urb_list[] before handing stale pointers to usb_free_urb(). The result is a resource leak and memory-corruption/denial-of-service condition rather than direct data theft, and our independent assessment scores this AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, materially below the vendor's 7.8 C:H/I:H/A:H rating; exploitation requires specific SDR hardware, the driver being loaded, and memory-pressure conditions, and there is no public exploit identified at time of analysis.
The Linux kernel's saa7164 media driver can leave a freed device structure dangling on the global saa7164_devlist when PCI BAR memory-region allocation fails during probe, because saa7164_dev_setup() adds the device to the list before calling get_resources() and never removes it on that error path; the probe cleanup then frees the device while the global list still points at it. Affected systems are those running the saa7164 driver against an SAA7164-based (NXP/Philips) TV capture card such as a Hauppauge HVR-22xx, and effectively any kernel built with CONFIG_VIDEO_SAA7164; the flaw was introduced with commit 443c1228d50518f3c550e1fef490a2c9d9246ce7 and is fixed in Linux 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5 (mainline 7.3-rc1). No public exploit has been identified at time of analysis (no CISA KEV entry, no published POC, no EPSS signal in the supplied data), and the vendor's CVSS 8.4 is not supported by our independent assessment, which rates the issue CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L and concludes real-world risk is LOW: the trigger is a hardware/probe-time resource failure rather than an attacker-controlled input, there is no remote vector, and no default configuration is affected.
Use-after-free in the Linux kernel's TI VPE/VIP media capture driver (media: ti: vpe) allows a locally authenticated attacker who can open and stream from a VIP /dev/videoN node to trigger memory corruption by racing stream teardown against outstanding interrupt work. The driver's VIP overflow recovery worker - armed from the hardirq handler when a FIFO overflow is detected - and the VPDMA list-complete path both continue to dereference stream, port, and device state after vip_release_stream() or free_stream() has freed those resources, because vip_stop_streaming() masks the per-list IRQs without synchronizing the hardirq handler or disabling recovery_work. Exploitation requires local access plus the ability to induce a FIFO overflow and win a tight timing window against file release or unbind/remove, so our independent assessment rates this AC:H with limited confidentiality and integrity impact but high availability impact (NVD scores it 7.8 AV:L/AC:L/PR:L). No public exploit code was identified at time of analysis, and the flaw is hardware-specific to TI Davinci/OMAP/AM-class SoCs with VIP capture hardware.
Out-of-bounds array access in the Linux kernel V4L2 control framework for stateless HEVC decoders lets a local user who can write to a V4L2 device node (/dev/video*) supply HEVC SPS short-term and long-term reference picture set counts that exceed the HEVC limits of 64 ST RPS sets and 32 LT references, so a decoder driver that trusts those counts can index past the EXT SPS dynamic arrays. The published CVSS vector rates this as 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), whereas our independent assessment scores it lower (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) because the flaw only manifests when a stateless HEVC decoder driver consumes the attacker-supplied counts without performing its own bounds validation; there is no public exploit identified at time of analysis and no CISA KEV entry. Vendor-released fixes are available in Linux 7.2.5 and 7.3-rc1.
Double-free in the Linux kernel's legacy zoran V4L2 media driver on teardown allows a local user who can trigger device/driver removal to kfree() the same registered video_device twice, crashing the kernel or corrupting kernel memory. Only systems where the zoran driver is bound to real Zoran ZR36057/ZR36067-based PCI MJPEG framegrabber hardware (Buz, DC10, LML33-class cards) are affected, and the flaw is reachable only through teardown paths such as module unload, PCI unbind/removal, or driver shutdown - not through normal runtime device I/O and not remotely. Vendor patches are available across maintained stable branches (6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5, and 7.3-rc1); exploitation requires the local authenticated context indicated by the CVSS vector (PR:L), and no public exploit code or confirmed active exploitation was identified at time of analysis. The practical impact is bounded to local denial of service because the affected hardware is obsolete and rarely deployed and the outcome is a crash rather than a controlled memory write.
Kernel crash (NULL pointer dereference) in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver, in the EDIF (encrypted FC / FC security) RX security-association delete check, allowing a host using that driver and feature to be taken down by a kernel oops in interrupt context. Only systems with a QLogic FC adapter, the qla2xxx driver loaded, and EDIF/FC-SP encryption in use are exposed; the assessed vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H (integrity and confidentiality unaffected, availability high), which is considerably narrower than the vendor's published AV:N/AC:L/PR:N rating and reflects that triggering the fault depends on a driver-internal abort/return timing race rather than remotely supplied network input. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor patches are already released for the affected stable branches.
A race condition in the Linux kernel's qla2xxx QLogic Fibre Channel driver allows a concurrent vport deallocation to free an NPIV virtual port while the format-1 report-ID-acquisition path still dereferences it, producing a use-after-free. The flaw is reachable only on systems that run a qla2xxx-driven QLogic FC HBA with NPIV virtual ports configured and that grant an attacker the local privilege needed to create and tear down virtual ports; the window is narrow (AC:H) and no attacker-controlled network input reaches the freed pointer, so the realistic outcome is a kernel crash or denial of service rather than controlled memory corruption. An independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H, notably lower than the published AV:N/PR:N vector, and no public exploit has been identified at time of analysis.
Repeated command aborts in the Linux kernel's qla2xxx (QLogic Fibre Channel) driver can reinitialize an already-queued work item, corrupting workqueue list state and leading to host crashes, hangs, or a looping worker - a denial-of-service condition on systems using NVMe over Fibre Channel. Affected code exists from the introduction commit e473b3074104ee09227cfbba5f872e3ea15dd280 (reported as Linux 4.17) onward, and fixes are available in stable releases 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1. No public exploit code has been identified at time of analysis, and the bug is a driver-internal timing race rather than an attacker-invokable primitive: triggering requires a host with a qla2xxx HBA actively handling NVMe-FC FCP or LS I/O where two aborts for the same command race (for example, concurrent transport teardown and a timeout-driven abort), so our assessment rates it substantially lower than the vendor's headline CVSS of 8.8 (AV:A/PR:N) - a local, high-complexity race with no confidentiality impact.
Concurrent NVMe-FC I/O submission in the Linux kernel's qla2xxx QLogic Fibre Channel driver can corrupt the hardware request-ring producer state, producing duplicated or dropped commands. The defect affects hosts running the qla2xxx driver with a QLogic FC HBA configured for NVMe-over-FC that uses ha->base_qpair; qla_nvme_ls_reject_iocb() advances the ring and rings the request-in doorbell via __qla2x00_alloc_iocbs() and qla2x00_start_iocbs() (both of which assume hardware_lock is held) but two of its callers, qla_nvme_xmt_ls_rsp() and qla2xxx_process_purls_pkt(), invoke it without holding qp_lock_ptr. Our independent assessment rates this as a local, race-window-dependent integrity/availability issue (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L), materially lower than the vendor's NVD score of 9.8, because the reject events are driven by Fibre Channel fabric/transport conditions rather than attacker-supplied input and require precise concurrency with normal base-ring submission; there is no public exploit identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV).
Memory corruption and kernel crashes in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver arise from an integer truncation when the driver derives its request/response queue counts from the adapter's advertised MSI-X vector count. Affected systems are those running the CONFIG_SCSI_QLA_FC driver and bound to a QLogic FC HBA that reports a boundary MSI-X count (257 vectors, which truncates to zero in the u8 queue-count fields, or exactly 1), after which qla2x00_alloc_queues() obtains ZERO_SIZE_PTR from kzalloc_objs(struct req_que *, 0) and then dereferences it via ha->req_q_map[0]; target-mode configurations can additionally underflow max_req_queues from 0 to 255. Exploitation requires physical or firmware-level control of a PCI/FC device (per our independent assessment of CVSS:3.1/AV:P/AC:H/PR:N/UI:N, C:N/I:L/A:H) rather than any network or unprivileged-user input, and there is no public exploit identified at time of analysis. Vendor patches are available in the referenced stable tree commits.
A use-after-free read in the Linux kernel's qla2xxx SCSI driver allows a local low-privilege (authenticated) user on a host with a QLogic cs84xx-capable Fibre Channel HBA to dereference freed memory by reading the 84xx_fw_version sysfs attribute while the adapter is being torn down. The race is bounded to the teardown window between qla84xx_put_chip() freeing ha->cs84xx and scsi_remove_host() draining the sysfs show handler, and since the dereference in qla24xx_84xx_fw_version_show() is read-only the realistic impact is an information leak or kernel crash rather than controlled corruption, meaning the vendor CVSS of 7.8 overstates real risk for this narrow, hardware-dependent timing bug. There is no public exploit identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); vendor patches are available in the stable kernel releases listed in remediation.
Wild-pointer dereference in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver lets an unexpected STATUS_TYPE completion IOCB reach a SCSI-only fast path, where the srb union is reinterpreted so sp->u.scmd.cmd reads as a non-NULL garbage pointer and is dereferenced. Only hosts running the qla2xxx driver with a physical QLogic FC HBA are exposed, and only when the adapter firmware or FC fabric delivers a mis-typed status IOCB that coincides with a live non-SCSI outstanding handle; the assessed vector is CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H, so the realistic outcome is a kernel crash rather than reliable code execution. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor patches are available for all maintained stable branches.
Use-after-free in the Linux kernel qla2xxx QLogic Fibre Channel SCSI driver lets a local user who can trigger queue-pair teardown reach freed request-queue memory through a late response-queue interrupt. On hosts with a QLogic FC HBA using MSI-X multiqueue qpairs, qla2xxx_delete_qpair() frees the request queue via qla25xx_free_req_que() before the response-queue IRQ is released in qla25xx_free_rsp_que(), so a response interrupt firing in that window causes qla2xxx_msix_rsp_q() to queue qpair->q_work and qla_do_work() -> qla24xx_process_response_queue() to dereference the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path). The result is full memory corruption with high confidentiality, integrity, and availability impact, but exploitation requires winning a narrow local race during qpair deletion; no public exploit code or active exploitation was identified at time of analysis, and vendor patches are available.
A double-completion race in the Linux kernel's qla2xxx QLogic Fibre Channel driver can cause a use-after-free write into a freed on-stack completion structure, leading to kernel memory corruption, a kernel crash, or potential local privilege escalation. Only hosts with a QLogic FC HBA and the qla2xxx driver loaded are affected, and the fault requires qla24xx_async_abort_cmd() to fail while the response ISR completes the same SRB handle at almost the same instant the async IOCB timeout handler re-scans outstanding_cmds[], so the attacker must win a very narrow concurrency window - local access only and no network reachability. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor patches are available in the stable releases 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and the NVD score of 9.8 (AV:N/AC:L/PR:N) should not drive prioritization given the assessed vector of AV:L/AC:H/PR:L/UI:N.
An out-of-bounds read in the Linux kernel's qla2xxx Fibre Channel host bus adapter driver (qla2x00_status_entry()) allows a hostile, compromised, or malfunctioning FC storage target to leak adjacent response-ring or heap memory into the local SCSI sense buffer of a host using a QLogic 24xx/29xx-class HBA. The bug is an unsigned integer underflow: the target-supplied 32-bit sf.rsp_data_len (rsp_info_len) is subtracted from the IOCB data-area size (par_sense_len, 28 bytes on 24xx and 60 bytes on 29xx) without a clamp, so oversized values wrap par_sense_len to a huge number and advance sense_data past its bounds before the capped memcpy in qla2x00_handle_sense(). Vendor-released patches are available in stable branches 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and no public exploit has been identified at time of analysis; the vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:H) substantially overstates real-world risk, since the attacker must already occupy a trusted target role on the Fibre Channel fabric and the disclosed memory is bounded to at most SCSI_SENSE_BUFFERSIZE of local ring/heap data.
Concurrent host_map btree corruption can occur in the Linux kernel's qla2xxx QLogic Fibre Channel driver because the format-1 branch of qla24xx_report_id_acquisition() releases vport_slock before invoking qla_update_host_map()/qla_update_vp_map(), which mutates ha->host_map without the serialization the function contract requires. Only systems running the qla2xxx driver with a QLogic FC HBA and NPIV virtual ports configured (a privileged local configuration) exercise this code path, and triggering it depends on winning a narrow, non-deterministic timing race against another host_map update. The result is kernel-internal data-structure corruption rather than direct data theft; no public exploit code has been identified and the issue is not confirmed as actively exploited (no CISA KEV).
A folio reference-count imbalance in the Linux kernel's f2fs filesystem lets a local user who can drive the redirty_blocks() path over-decrement a pinned folio when read_cache_folio() fails before any folio is pinned and readahead has already cached that same folio, after which drop_caches or reclaim can emit "BUG: Bad page state" and corrupt kernel memory state. Only kernels that include the folio-conversion commit 5951fee46bef are affected, i.e. Linux 6.16 through the fixed releases 6.18.51, 7.2.5 and 7.3-rc1. Exploitation requires local access with low privileges (CVSS:3.1/AV:L/PR:L) and is gated on a non-deterministic failure-plus-readahead race, so reliability is poor (AC:H); the independent assessment rates confidentiality impact as none with limited integrity and high availability impact, and no public exploit has been identified at time of analysis.
A use-after-put race in the Linux kernel's f2fs filesystem during large-folio invalidation allows a local low-privileged attacker who can concurrently drive a truncate or folio split against f2fs_get_read_data_folio() to leave stale xarray slots and corrupted page state in the page cache, resulting in livelocks, bad page statistics, and possible memory corruption. Only kernels built with f2fs large/compound folio support are affected - the flaw was introduced on the v6.18/7.0 development line (commit 05e65c14ea59a401cec4284e9d612f9d5dc1b3f8 and later) and is fixed in the vendor-released 7.2.5 stable update and 7.3-rc1. The vendor rates this 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), but independent assessment downgrades it to AC:H/C:L because a narrow timing window must be won and the outcome is memory corruption or denial of service rather than reliable code execution; no public exploit identified at time of analysis.
Incorrect node-block validation in the Linux kernel's f2fs filesystem causes f2fs_sanity_check_node_footer() to be invoked with the wrong folio index, so the sanity check re-validates the same nid instead of the node actually being read, allowing a local user who is permitted to mount a crafted or corrupted f2fs volume to bypass the intended footer validation and trigger out-of-range metadata access - most plausibly a kernel crash or denial of service. The affected code path is reachable only when an attacker-influenced f2fs image is mounted (CVSS AV:L, PR:L), and exploitation requires supplying malicious on-disk metadata, which raises real attack complexity. Vendor patches are available in stable releases 6.18.51 and 7.2.5 (plus mainline 7.3-rc1); no public exploit identified at time of analysis, and the CNA's boilerplate 7.8 HIGH score (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) overstates the issue relative to the assessed vector AV:L/AC:H/PR:L/UI:N/C:L/I:L/A:H, whose dominant impact is availability loss.
Kernel oops and duplicate/incorrect DMA unmapping in the Linux kernel SPI core can occur when __spi_map_msg() partially fails: if the RX scatter-gather mapping fails after the TX mapping succeeds, or if a later transfer's TX mapping fails after earlier transfers were mapped, the tx_sg_mapped/cur_tx_dma_dev bookkeeping is left inconsistent, so the subsequent spi_unmap_msg() may unmap a TX mapping twice or call dma_unmap_sg_attrs() with a NULL or stale device struct. Affected systems are Linux kernels 6.11 through the pre-fix stable trees, and exploitation requires local execution on a platform whose SPI controller performs DMA-mapped transfers (typically embedded/ARM SoC hardware) plus an actual DMA mapping failure, which normally arises only under memory pressure or address-space/IOMMU exhaustion and cannot be induced remotely; no public exploit code was identified at time of analysis. Note that the vendor-supplied CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is severely inconsistent with the technical description and should be treated as boilerplate auto-scoring, not a real signal - the independent assessment is AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H, i.e., a local, high-complexity availability-only defect.
An out-of-bounds read in the Linux kernel's iSCSI target (LIO) login handling lets a remote, unauthenticated initiator read past the end of a heap buffer when the target portal is configured to require CHAP authentication. Because login->req_buf is kzalloc'd with exactly MAX_KEY_VALUE_PAIRS (8192) bytes and iscsit_get_login_rx() accepts payload_length plus padding, a login PDU with DataSegmentLength between 8189 and 8192 fills the buffer completely, leaving no NUL terminator; the buffer is then consumed by length-unaware C string routines such as kstrdup(), strstr() and strlen_semi(), and convert_null_to_semi() rewrites embedded NULs to ';', so adjacent slab memory is walked and disclosed. The flaw is reachable pre-authentication only on portals that explicitly require CHAP (portals that do not require authentication rewrite AuthMethod to None in iscsi_login_zero_tsih_s2() and never enter the CHAP path), requires no user interaction, and at the time of analysis there is no public exploit identified, though a vendor patch is available and the affected kernel versions are broad.
An out-of-bounds write in the Linux kernel's SCSI bsg io_uring completion path allows a local attacker with low privileges (CVSS PR:L) to overrun a user-supplied response buffer that is smaller than SCSI_SENSE_BUFFERSIZE, because the completed sense length is copied back without being capped to the caller's max_response_len. The io_uring-backed bsg passthrough interface that exposes the flaw was introduced in kernel 7.1 and is fixed in 7.2.5 and 7.3-rc2, so exposure is limited to very recent kernels on hosts where a bsg device node is reachable; no public exploit identified at time of analysis. The vendor's CVSS 7.8 (C:H/I:H/A:H) overstates real-world risk - our independent assessment scores it C:N/I:L/A:H, with the impact largely a memory-corruption/denial-of-service concern rather than a full confidentiality breach.
Local privilege escalation in the Linux kernel's SCSI bsg io_uring passthrough path (bsg_uring_cmd) allows an authenticated low-privileged local user (PR:L) to corrupt kernel memory via an out-of-bounds write, potentially escalating privileges or crashing the host. The handler validates fields read directly out of the user-shared, mmap'd io_uring SQE, so a racing thread can enlarge request_len after the bound check but before copy_from_user(), overflowing the fixed-size scmd->cmnd buffer inside the kernel. Affected are kernels built with bsg io_uring passthrough support (EUVD lists Linux 7.1 in the affected commit range), with exploitation requiring local access to a /dev/bsg device node plus a multi-threaded racer that wins a narrow check-to-use window; the vendor rates it 7.8 while the independent assessment agrees it is a genuinely serious bug but raises attack complexity to AC:H because success is probabilistic per attempt. No publicly available exploit code was identified at the time of analysis, and no KEV listing was provided.
An out-of-bounds write in the Linux kernel's megaraid_sas driver (megasas_make_prp_nvme) lets a locally present user submitting large block I/O to an NVMe drive behind a Broadcom/LSI MegaRAID controller overflow the cmd->sg_frame DMA pool buffer, corrupting such a list to run up to a full page past its allocation. The flaw is only reachable on Linux 6.17 and later, after block commit 9b8b84879d4a raised the default maximum transfer size to 4 MiB, and on drives whose firmware reports a large MDTS so max_hw_sectors is not clamped; systems with small-MDTS drives never hit the condition. Per the independent assessment, the vendor score of 7.8 overstates real-world risk (assessed AV:L/AC:H/PR:L with C:N/I:L/A:H): exploitation requires local access plus specific storage hardware, is not remotely reachable, and no public exploit was identified at time of analysis. Consequences range from a kernel page fault and crash (availability) to silent corruption of a neighbouring in-flight command's PRP list when the following page happens to be mapped.
Linux kernel pm8001 SAS/SATA HBA driver contains an error-path cleanup bug that can leave MSI-X interrupt handlers installed when request_irq() fails during driver initialization, because the rollback loop uses the failing index instead of the previously registered vector index. Systems with a PMC-Sierra/Adaptec 8001-series controller bound to the pm8001/pm80xx driver and kernel versions from 4.11 up to the fixed releases are affected. The issue is not attacker-reachable-it requires a non-attacker-influenced interrupt allocation failure-so independent assessment rates it low-impact availability-only (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L), and no public exploit has been identified at time of analysis.
A race condition in the Linux kernel futex priority-inheritance requeue path (FUTEX_CMP_REQUEUE_PI) allows a waiter's stack-allocated futex_q to be freed while a concurrent requeue task is still about to call rcuwait_wake_up() on it, producing a slab-out-of-bounds use-after-free that typically surfaces as a KASAN report and kernel crash. Only kernels built with PREEMPT_RT reach the affected code path; on such systems any local, unprivileged process can trigger it, but exploitation requires winning a narrow, non-deterministic timing window in which an early wakeup (futex timeout or delivered signal) races the concurrent PI requeue. No confirmed active exploitation and no public exploit code had been identified at time of analysis, and the practical outcome is denial of service rather than code execution or data disclosure.
Linux kernel builds with HID-BPF support (CONFIG_HID_BPF) can be crashed by a race that double-releases a HID device reference: a BPF map delete invoking hid_bpf_unreg() (no BPF_F_LINK) can run concurrently with device destruction via hid_destroy_device(), so both paths call hid_put_device() on the same registration reference and the struct hid_device is freed while teardown is still executing inside hid_destroy_device(). The attacker must already hold the local privileges required to attach a HID-BPF struct_ops program (CAP_BPF/CAP_SYS_ADMIN, effectively root) and win a narrow timing window, so the independent assessment is materially lower than the vendor's 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and rates it as a crash-class fault (A:H, I:L, C:N) rather than code execution or data disclosure. No public exploit code was identified at time of analysis and the flaw is not in CISA KEV; patched stable releases (6.12.110, 6.18.51, 7.2.5, with a 7.3-rc2 fix) are available from the vendor.
Out-of-bounds reads and writes in the Linux kernel's hid-rmi driver let a physically attached HID device that advertises the Synaptics RMI report IDs (RMI_DEVICE) leak kernel heap memory and corrupt adjacent slab objects during probe, with the stolen bytes surfaced to any local user through a mode-0444 sysfs attribute. Unpatched kernels from 3.16 onward are affected up to the listed fixed releases, which include 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc2; no public exploit code has been identified at time of analysis. The vendor CVSS of 8.8 (AV:A/PR:N/UI:N) overstates real-world risk - our assessment is AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H - because an attacker must supply the device locally (or already be root to force a bind via new_id) and the code paths only run during probe, though the confidentiality impact is real since the leaked register data is exposed to unprivileged userspace and echoed back to the device itself.
An out-of-bounds read in the Linux kernel's Wacom Bluetooth HID driver (wacom_intuos_pro2_bt_irq) allows an attacker in Bluetooth range who controls, spoofs, or merely operates a malfunctioning paired peripheral advertising a Wacom Intuos Pro/Intuos BT VID/PID to make the kernel parse a report shorter than the branch's fixed offsets, reading past the end of the received buffer. Because the driver force-registers pen, pad and touch input nodes for the matched device type via wacom_setup_device_quirks(), the leaked bytes are forwarded to userspace through evdev (MSC_SERIAL, ABS_MISC, ABS_WHEEL), giving a concrete confidentiality channel in addition to the immediate availability impact of a kernel OOB access on short descriptors. The reported CVSS is 8.1 (AV:A/AC:L/PR:N/UI:N), while our independent assessment rates it CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H - still adjacent and unauthenticated from a credential standpoint, but requiring the victim to pair/trust the hostile peripheral and, for any real confidentiality payoff, a local process consuming the evdev stream. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (not CISA KEV); vendor patches are available in current stable trees.
A use-after-free race condition in the Linux kernel's device-mapper (dm) subsystem can be triggered when two concurrent DM_TABLE_LOAD ioctls are issued against the same device and one succeeds while the other fails, allowing the unlocked walk of md->table_devices in dm_setup_md_queue to dereference memory already freed by dm_table_destroy. The vendor scored this 7.8, but our independent assessment places it at CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H - exploitation requires local, root-equivalent CAP_SYS_ADMIN access to /dev/mapper/control and winning a narrow, non-deterministic timing window, so the realistic worst case is a host crash or denial of service rather than code execution or data disclosure. No public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV; vendor patches are available for the 6.1, 6.6, 6.12, 6.18 and 7.2 stable branches.
Local attackers holding CAP_SYS_ADMIN can crash or destabilize the Linux kernel by racing the device-mapper resume ioctl against a concurrent device removal on the same mapped device, so the table is torn down in __dm_destroy without the postsuspend callback the dm targets depend on. The most concrete consequence documented is a use-after-free in the dm-integrity target, whose reboot notifier is left registered when postsuspend is skipped, while other targets may simply misbehave; the independent assessment rates this as a privilege-gated, non-deterministic denial-of-service rather than code execution or data disclosure, materially below the vendor's 7.8 HIGH score. No public exploit code has been identified at time of analysis, and the flaw is not known to be actively exploited.
A functional regression introduced in the Linux kernel's dma-direct allocator by commit 5b138c534fda causes dma_direct_alloc_from_pool() to hand back a CPU address where its caller dma_direct_alloc_pages() expects a struct page pointer, so that path dereferences an address as page metadata and can corrupt state or crash the kernel. Only kernels built with the atomic DMA coherent pool (CONFIG_DMA_COHERENT_POOL) and configurations that route coherent allocations through the atomic pool - typically GFP_ATOMIC or restricted/non-coherent DMA device paths - are exposed, and the bug is reachable only by local kernel/driver DMA activity with low privileges, not over a network. No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV entry); severity should be read as the low-CIA/availability-heavy impact assessed locally (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) rather than the higher network-adjacent score carried in some feeds.
Denial of service in the Linux kernel's fsl-edma DMA engine driver lets a local user with write access to tracefs event-injection files crash the system by causing the fsl_edma trace event handler to dereference a stale struct fsl_edma_engine pointer. Affected systems are those running NXP/Freescale eDMA hardware (for example i.MX or Layerscape) with kernel tracing enabled; the independent assessment rates this as a local DoS requiring root/CAP_SYS_ADMIN (assessed CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H), which is narrower than the vendor's 7.8 score. A local trigger is described in the upstream fix, so publicly available exploit code exists, but there is no CISA KEV entry indicating active exploitation.
Improper freeing of a kernel heap buffer in the Linux kernel's cpuidle device-tree idle power-domain support (dt_idle_genpd) can crash affected systems when a device-tree idle power domain is torn down. Kernels built with CONFIG_DT_IDLE_GENPD and instantiated DT idle power domains - introduced by commit 9d976d6721df (present since Linux 5.18) and fixed in stable releases 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5/7.3-rc2 - are affected, which in practice means ARM/embedded PSCI-style platforms whose firmware provides cpuidle power-domain nodes. Triggering requires local privileged or boot-time influence over device-tree content or the ability to force genpd teardown/probe failure, so this is not remotely reachable and no public exploit has been identified at time of analysis; the practical impact is a kernel crash rather than code execution or data disclosure, despite the 8.4 base score reported by NVD-style scoring (our own assessment is AV:L/AC:H/PR:H with C:N/I:N/A:H).
A use-after-free race in the Linux kernel CephFS client allows a local process to crash the kernel while opening a file on an in-kernel CephFS mount, with a secondary integrity impact on the access-check result. The bug lives in ceph_mds_check_access(), which walks the mdsc->s_cap_auths array without holding mdsc->mutex, so a concurrent MDS session OPEN (reopen) that replaces and frees that array under the mutex can free the strings mid-traversal - the oops trace shows ceph_mds_check_access reached via ceph_atomic_open and do_sys_openat2. Affected systems are Linux 6.10 and later (where the s_cap_auths access-checking code exists) that mount CephFS with the in-kernel client; exploitation is local-only, requires a narrow timing window (AV:L/AC:H/PR:L per our assessment), and no public exploit code has been identified at time of analysis. The vendor-assigned CVSS of 9.8 (AV:N/AC:L/PR:N) is severely inflated relative to the described local race.
A use-after-free race condition in the Linux kernel kprobes subsystem (CVE-2026-89988) lets a highly privileged local actor corrupt kernel memory by racing a blacklist traversal against a concurrent kernel module unload. Specifically, __within_kprobe_blacklist() walks kprobe_blacklist without holding kprobe_mutex, while kprobe_remove_area_blacklist() unlinks and immediately kfree()s those same entries when a module is unloaded, so a traversal that lands in the race window dereferences freed memory. The upstream fix converts the list to RCU (guard(rcu)(), list_for_each_entry_rcu(), list_add_tail_rcu(), list_del_rcu(), kfree_rcu()); it is not known to be exploited and no public exploit code was identified at time of analysis, and EPSS/KEV data are absent. Our independent assessment rates this materially lower than the published CVSS 7.8: it requires local access with the ability to register kprobes (root / CAP_SYS_ADMIN / CAP_SYS_MODULE or the debugfs kprobe interface) plus concurrent module load/unload churn, and the timing window is narrow (AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H, moderate, ~4.7).
A context-inappropriate allocation in the Linux kernel's weighted-interleave memory policy path causes a sleeping (GFP_KERNEL) allocation to be performed while executing in atomic/RCU context. The bug exists only in kernels that provide the MPOL_WEIGHTED_INTERLEAVE mempolicy, introduced in Linux 6.9, and is triggered when an authenticated local user has that policy set on the current task while an rhashtable bucket-table allocation rehashes under rcu_read_lock() with GFP_ATOMIC and falls back to vmalloc (__vmalloc_node_range_noprof → vm_area_alloc_pages → alloc_pages_bulk_mempolicy → alloc_pages_bulk_weighted_interleave), which then hardcodes GFP_KERNEL for its temporary weights array. The observable impact is a might_alloc()/might_sleep() splat - most visible with CONFIG_DEBUG_ATOMIC_SLEEP enabled - with no confidentiality or integrity consequence and at most a minor availability effect; the window is timing- and workload-dependent and not directly attacker-controlled, and no public exploit has been identified at time of analysis. The vendor's assigned CVSS of 7.8 is substantially higher than the assessed real-world risk, which our analysis rates as low (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).
Cross-node folio migration in the Linux kernel 7.1 memory cgroup controller can leave a folio's objcg pointing at a different node than the LRU list the folio actually belongs to, so memcg reparenting resolves the wrong lruvec and takes the wrong lru_lock, corrupting memory-cgroup accounting and risking kernel failure (assessed availability impact High, integrity Low, confidentiality None). Exposure is narrow: it requires the memory controller active (default in modern container/systemd deployments), genuinely multi-node NUMA hardware, local authenticated access (CVSS vector PR:L) to trigger cross-node migration, and a race with memcg_reparent_objcgs() during cgroup offline in the non-atomic window between objcg and LRU-splicing iterations; single-node systems and kernels before 7.1 are unaffected. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; vendor fixes are 7.2.5 and 7.3-rc1, so the vendor score of 7.8 (AV:L/AC:L/.../C:H/I:H/A:H) materially overstates real-world risk relative to the assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H.
Uninitialized spinlock use in the Linux kernel's ALSA 'harmony' driver (HP PA-RISC CS4215 sound hardware) can crash the system during driver initialization, because snd_harmony_create() calls request_irq() before h->lock and h->mixer_lock are initialized and a pending interrupt can fire the handler against garbage lock state. Only systems with this legacy driver present and probing on real or emulated PA-RISC hardware are exposed, and triggering it requires a narrow hardware timing window during boot or root-privileged module load, so there is no public exploit identified at time of analysis and independent assessment rates real-world risk as low despite the vendor's 8.4 (HIGH) score - the assessed impact is availability-only (local denial of service/crash) under a privileged, high-complexity precondition. Vendor patches have been published as upstream commits and are shipped in the stable releases listed below.
A race condition in the Linux kernel ALSA PCM (sound) subsystem allows a local, authenticated user with access to a sound device node to trigger conflicting PCM state transitions - specifically, an atomic trigger-start racing a non-atomic hw_params, hw_free, or prepare operation on the same stream. The realistic outcome is internal state inconsistency and a kernel ODEBUG warning (as reported by syzkaller), not memory corruption or privilege escalation; the distro-assigned CVSS of 7.8 is substantially overstated relative to the assessed vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), which reflects low availability impact only. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so exploitation requires winning a tight, non-deterministic timing race from an already-privileged local position.
Double free in the Linux kernel's NVMe-over-Fabrics Fibre Channel (nvme-fc) transport lets a privileged local user corrupt kernel memory when an nvme-fc controller creation attempt fails. The bug lives on an error path: nvme_fc_init_ctrl() jumps to out_put_ctrl: when nvme_add_ctrl() fails (reached when dev_set_name() cannot allocate memory), bypassing the pointer clear that nvme_fc_ctrl_free() relies on, so the transport frees the fabrics options and nvmf_create_ctrl() frees them a second time - KASAN reports a slab-use-after-free in nvmf_free_options(). Introduced by commit 1a9e218195a5 and present in kernels from 6.11 through the fixed stable releases, exploitation requires root/CAP_SYS_ADMIN, the non-default nvme-fc transport, and a narrow allocation-failure window (memory pressure or kernel fault injection); no public exploit identified at time of analysis, and the assessment rates availability impact high with confidentiality and integrity impact none.
Denial of service in the Linux kernel's NVMe-over-TCP (nvme-tcp) host driver, where nvme_tcp_handle_c2h_data() accepts a controller-to-host data PDU for a command that did not request a read; the receive path then hits WARN_ON_ONCE(i->data_source) inside _copy_to_iter(), returns -EFAULT, and resets the controller. The impacted component is the initiator side of the NVMe-oF TCP transport, so hosts are only at risk when they attach to a malicious or compromised NVMe-oF TCP target that can dictate PDU sequencing; there is no public exploit identified at time of analysis, and the practical severity is modest because the trigger requires control of the storage controller the host talks to (inverted trust model). Impact is normally limited to a failed command plus a controller reset, but on hosts booted with panic_on_warn the same warning becomes an immediate kernel panic and full system outage, which is the key amplifying condition behind the assigned A:H rating.
A race condition in the Linux kernel's NVMe-over-Fabrics target authentication code (nvmet-auth) can leave a queue structure (struct nvmet_sq) freed or reused while the auth_expired_work delayed-work callback is still executing, potentially crashing or corrupting the memory of the target host. Exposure is limited to Linux systems acting as NVMe-oF targets (nvmet) with in-band DH-HMAC-CHAP authentication enabled: an attacker must be positioned on the NVMe-oF fabric (TCP or RDMA), be able to open and tear down authenticated sessions, and win a narrow, non-deterministic timing window during transport teardown, which is why our independent assessment rates the issue well below the vendor's 9.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H) and finds no confidentiality impact despite the 'Information Disclosure' tag. Vendor patches are available in the stable branches (6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc2), and no public exploit or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds write in the Linux kernel's NVMe-over-Fabrics TCP target (nvmet-tcp) allows a network-reachable initiator to write four attacker-controlled bytes past a 128-byte receive buffer by sending a duplicate ICReq PDU after a header digest has been negotiated, corrupting adjacent queue state. The bug is reachable before authentication (CVSS PR:N), and the assessed impact is high availability (target crash or teardown) with a limited integrity effect and no confidentiality impact. Vendor patches exist for all supported stable trees, and no public exploit code or confirmed active exploitation was identified at time of analysis; practical exposure is confined to hosts that actually export an NVMe/TCP target subsystem, typically on port 4420.
Remote, unauthenticated denial of service in the Linux kernel's NVMe-over-TCP target (nvmet-tcp) lets a permitted host wedge the target workqueue by racing an unsolicited H2CData PDU ahead of the target's Ready-to-Transfer message. A write command that takes the R2T path is completed twice, causing a response-list entry to point to itself and, depending on CONFIG_DEBUG_LIST, triggering a kernel BUG or an infinite loop/soft-lockup in the nvmet_tcp workqueue. Only hosts configured as NVMe/TCP targets (particularly subsystems using allow_any_host) are affected; no public exploit code has been identified at time of analysis, and the assessed CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
An out-of-bounds write in the Linux kernel's device-memory migration helpers (mm/migrate_device) allows a local user who holds a file descriptor to a ZONE_DEVICE/HMM-capable device to corrupt kernel memory. When a compound (transparent huge) folio is migrated into device memory and its page-granular span extends past the end of the caller-supplied npages PFN array, migrate_device_range() and migrate_device_pfns() clear folio entries past the array boundary; the path is exercised in practice by dmirror_fops_release() on /dev/hmm_dmirror0 and by GPU shared-virtual-memory drivers such as nouveau or amdgpu SVM. Exploitation is local only and conditional, requiring a device-memory migration-capable kernel build and a specific huge-page-versus-range boundary condition (assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, integrity and availability impact with no confidentiality impact); no public exploit identified at time of analysis.
Out-of-bounds write in the Linux kernel's nvdimm BTT (Block Translation Table) driver allows a privileged local attacker who can supply a crafted or foreign BTT arena to corrupt kernel memory, primarily degrading availability and potentially altering data. The flaw is triggered when the BTT info block's unvalidated nfree field is set below the host's per-lane count (ND_MAX_LANES), so the I/O path indexes freelist[]/rtt[] arrays past their allocations; exploitation requires local root/CAP_SYS_ADMIN or physical control over the persistent-memory medium being probed, making it a low-real-risk issue despite a high base score. There is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); EPSS data was not supplied.
Incorrect PFN bookkeeping in the Linux kernel's PowerPC compound vmemmap population path (vmemmap_populate_compound_pages) causes the kernel to compute the wrong pfn_offset and therefore make the head/tail struct-page mapping decision for the wrong position within a compound page, which can corrupt vmemmap contents or crash the system when PowerPC systems exercise compound-page vmemmap optimization (ZONE_DEVICE / device-DAX / persistent memory or memory-hotplug configurations). This is a deterministic setup- or boot-time arithmetic miscalculation rather than an attacker-controlled primitive: the vendor CVSS of 7.8 assumes local, low-privilege access with high confidentiality and integrity impact, but an independent re-assessment scores it CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H, noting the vendor vector appears over-scored because triggering the mis-decision requires high privileges to drive memory hotplug/device configuration, depends on specific compound-page population and alignment conditions, and has no remote or unauthenticated vector. No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is limited to PowerPC (PPC) kernels, and vendor-released fixes are available in the 6.6.157, 6.12.110, 6.18.51, 7.2.5, and 7.3-rc1 stable/mainline trees.
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with host-side privilege to corrupt kernel state by attaching a second vfio-ap mediated device to a KVM instance that already owns one. On the resulting -EPERM error path, vfio_ap_mdev_set_kvm() fails to restore kvm->arch.crypto.pqap_hook, leaving it pointing at an mdev that is never tracked by matrix_mdev->kvm; when that mdev is later freed, a guest-executed PQAP instruction dereferences the stale hook through pqap_hook_rwsem and triggers the use-after-free. Exploitation requires an IBM Z/s390 host running KVM with vfio-ap enabled but is not remotely reachable, needs authenticated local privilege to configure mediated devices, and depends on error-path plus free-then-execute sequencing; no public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available in the stable trees.
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access when a privileged host administrator unplugs a control domain from a matrix mdev: vfio_ap_mdev_cfg_remove clears the wrong bit set with bitmap_andnot instead of intersecting with bitmap_and on the mdev's adm bitmap. The practical result is that a KVM guest on IBM Z hardware configured for AP (Adjunct Processor) passthrough retains access to control domains the host intended to remove, a residual-access/state-desynchronization condition rather than remote code execution, reached only when a host admin performs an explicit control-domain removal (CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-supplied 8.8 score (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) materially overstates real-world risk given that exploitation is confined to the rare s390 crypto-passthrough deployment mode and requires a trusted privileged reconfiguration action.
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the vfio-ap mediated-device driver: when the last AP adapter, domain, or control domain is removed from the host's AP configuration, the shadow APCB is cleared but the bitmap_andnot() return value is false for an empty result, so the do_hotplug flag never gets set and the guest's APCB is never refreshed. Only s390 hosts with CEX crypto adapters configured for guest passthrough are affected, exploitation is local and requires privileged host management access to modify the AP configuration, and no public exploit code has been identified at time of analysis. The practical consequence is a crypto-resource isolation failure in which the guest passively retains access to AP devices the administrator believes were unplugged, not memory corruption or code execution.
Out-of-bounds access in the Linux kernel MTD AFS (ARM Flash Structure) v2 partition parser lets crafted flash contents drive the image-information offset and region count beyond the bounds of the local image-info array, producing a kernel memory-safety fault during partition scanning. The code path is only reachable on platforms that enable and scan AFS v2 partitions, and per the independent assessment exploitation requires a local actor with high privileges (PR:H) - root or CAP_SYS_ADMIN write access to the raw MTD device, or physical replacement/tampering of the flash chip - with the malicious data consumed when the kernel parses the partition table at boot or device attach. It is deterministic once the crafted flash is in place, and no public exploit identified at time of analysis; the CVE carries an NVD base score of 8.0 while cross-checked analysis places the practical risk substantially lower because there is no remote or unprivileged path. Vendor-released fixes are available in the stable trees listed below.
A use-after-free in the Linux kernel's batman-adv (B.A.T.M.A.N. advanced) mesh networking module lets an attacker on the adjacent mesh trigger a kernel crash by exploiting stale receive-device metadata on reassembled fragments. When batman-adv merges buffered fragments it reuses the skb from the highest-numbered fragment; if the hard interface that carried that fragment is torn down before the fragment chain completes, the merged skb re-enters the receive path holding a freed skb->dev pointer, and the DAT and bridge loop avoidance handlers dereference it when computing the ARP header length. The assessed impact is availability only (kernel crash/DoS) with at most limited integrity effects, requiring a narrow race between fragment buffering and administrative interface removal; no public exploit code has been identified, no KEV listing exists, and exploitation is limited to the adjacent mesh segment (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H assessed; NVD published a higher 8.8 vector that this analysis does not corroborate).
An out-of-bounds read in the Amlogic Meson GXBB clock controller driver causes a kernel global-out-of-bounds report (KASAN: read of size 8 in gxbb_32k_clk_parents) during clock registration at boot on GXBB-based boards such as the WeTek Hub. The defect comes from a mux parent count that was left hard-coded after a stale parent entry was removed, so the driver walks one slot past the end of its parent array; affected code shipped in stable kernels including 5.4.292+, 5.10.236-5.10.269, 5.15.180-5.15.220, 6.1.134-6.1.187, 6.6.87-6.6.156, 6.12.23-6.12.109, 6.13.11-6.13.x, 6.14.2-6.14.x and the 6.15 mainline series, and is fixed in newer stable releases (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5, 7.3-rc1). There is no public exploit identified at time of analysis and no CISA KEV listing, and nothing more than a local unauthenticated vector exists in the CVSS data (AV:L, PR:N); our independent assessment rates it CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, far below the vendor's 8.0 vector, because the read is triggered solely by the driver's own probe and is not controllable by any user, network input, or configuration toggle.
A missing error check in the Linux kernel's Loongson ASoC sound-card ACPI probe path (loongson_card_parse_acpi) leaves the pointer returned by device_property_read_string() for the 'codec-dai-name' property uninitialized when that property is absent or invalid, and the stale pointer is dereferenced later during driver binding. Only LoongArch/Loongson platforms whose ACPI firmware omits or malforms codec-dai-name are affected, and reaching the bug requires the ability to supply or modify that firmware description - it is not reachable over the network and not triggerable by an unprivileged local user on a default, correctly-described platform. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor's CVSS 8.4 rating substantially overstates the assessed risk (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H), and the vendor vector is also internally inconsistent because it computes to 7.8 rather than 8.4.
A local use-after-free in the Linux kernel's Industrial I/O (IIO) subsystem can crash or corrupt the kernel when an anonymous IIO buffer handle is released while its underlying IIO device is being torn down at the same time. Only kernels built with the anonymous/DMABUF buffer interface introduced in 6.11 are affected, and the vendor-scored 7.8 severity is not supported by the evidence: exploitation requires local low-privileged access (CVSS PR:L), a narrow race with driver unbind or hot-unplug (AC:H), and results in denial of service (kernel memory corruption/crash) rather than the high confidentiality and integrity impact the vendor vector claims. Patches are available in the stable tree (6.12.110, 6.18.51, 7.2.5, and 7.3-rc1); no confirmed active exploitation (CISA KEV) and no public exploit code were identified at time of analysis.
A race-condition use-after-free in the Linux kernel's IIO (Industrial I/O) buffer DMA-fence implementation allows a local attacker with access to an IIO device exposing the DMABUF buffer interface to corrupt kernel memory by racing the fence's teardown against lockless RCU readers - the custom release path calls kfree() rather than deferring the free through RCU or the standard dma_fence_free() helper. The flaw affects kernels that include the IIO DMABUF buffer support introduced in 6.11 and was fixed in 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1; exploitation requires a vulnerable IIO DMABUF-capable device, a build with that support enabled, and a timing-dependent race window, so it is local-only and not deterministic. Per independent assessment the realistic impact is availability and limited integrity loss (AC:H, C:N/I:L/A:H) rather than the confidentiality breach suggested by the higher vendor-published score, and no public exploit code has been identified at time of analysis.
Use-after-free in the Linux kernel's IIO buffer DMABUF path where an iio_dma_fence can outlive the iio_dmabuf_priv structure that holds its embedded lock, so a fence signal or release callback can touch a freed lock object. Affected kernels are Linux 6.11 through the fixed releases 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and exploitation requires local access to a host whose hardware/driver exposes the IIO DMABUF buffer interface with permission to open the IIO device node (CVSS PR:L, no UI). The vendor advisory lists a patch, and no public exploit or CISA KEV entry was identified at time of analysis; our independent assessment rates this Medium (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) because the race window is timing-sensitive and the affected surface is driver-specific rather than universal, which is noticeably lower than the vendor-supplied 7.8 vector.
Use-after-free in the Linux kernel's IIO atlas-sensor driver (Atlas Scientific chemical sensors) is reachable when an IIO buffer is enabled and the driver is torn down: the devm-managed data-ready IRQ keeps queueing an irq_work that calls iio_trigger_poll(data->trig), and free_irq() during the devres unwind after atlas_remove() never flushes that pending work, so atlas_work_handler() can dereference an already-freed trigger/indio_dev via container_of(). The driver has existed since Linux 4.8 and is only present on systems with real Atlas Scientific I2C sensor hardware attached; exploitation requires authenticated local access (typically root privileges to unbind the device or unload the module), with an enabled buffer, and it is constrained by a narrow race-timing window - the assessed impact is low integrity and high availability (denial of service / memory corruption on teardown) with no confidentiality impact. No public exploit identified at time of analysis, and the flaw was closed upstream by calling iio_trigger_poll_nested() directly from the threaded handler so free_irq() drains it, with fixes shipped in 6.6.157, 6.12.110, 6.18.51 and 7.2.5.
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on x86 Intel VMX hosts, because vpid02 is not flushed on its first use after a VPID is recycled following an L1 guest's VMXOFF/VMXON cycle. Exploitation requires an attacker who already controls an L1 guest on a host running KVM with nested virtualization enabled (kvm_intel nested=1) where L1 uses VPID for its L2 guests, and success depends on KVM reusing a vpid02 value that still has TLB entries resident on the physical CPU, making the outcome timing- and reuse-dependent rather than deterministic. No public exploit has been identified at time of analysis, and our independent assessment rates the realistic impact well below the vendor's CVSS 8.8 - limited confidentiality and integrity loss with high availability impact under local, high-complexity preconditions (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H).
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. The independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - local hypervisor context, non-default configuration, no confidentiality impact, limited integrity and availability impact - and notes it is not exploitable against default (non-nested) KVM deployments; no public exploit code or confirmed active exploitation has been identified at time of analysis.
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM executes the L1 guest's INVVPID on whichever pCPU is currently active rather than on the pCPU where L2 last ran. When L1 migrates to another CPU, issues INVVPID, and then migrates back to the original CPU to resume L2, the stale VPID mappings on that original pCPU are never invalidated and vmx_vcpu_load_vmcs() does not request a KVM_REQ_TLB_FLUSH because vmcs02 never ran on a different pCPU. Affected are x86 hosts with non-default nested virtualization enabled and a malicious or buggy L1 guest controlling an L2 guest; exploitation requires local access to an L1 vCPU (PR:L) and a narrow cross-CPU scheduling/migration race, no public exploit code has been identified at time of analysis, and CISA KEV does not list this issue. The judged impact is primarily TLB corruption and nested-guest instability rather than a reliable code-execution or data-exfiltration primitive, consistent with an assessed vector of AV:L/AC:H/PR:L/S:C/C:L/I:L/A:H.
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through 6.18.50 and 7.x before 7.2.5 that are built with CONFIG_KVM_MMU_LOCKLESS_AGING=y. A local user able to run or drive a KVM guest (PR:L, no user interaction) can race the lock-elision window so that a writer populates a KVM_RMAP_MANY rmap and later frees its pte_list_desc chain while the lockless aging walk is still traversing it, yielding memory corruption of kernel slab memory; the race is timing-dependent (AC:H) and is driven by host memory reclaim rather than attacker-controlled scheduling, so exploitation is opportunistic rather than deterministic. No proof-of-concept or public exploit code has been identified at time of analysis and there is no evidence of active exploitation. Vendor scoring is 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), while independent assessment rates it 6.3 with AC:H and no confidentiality impact, reflecting the narrow, reclaim-triggered race window; it is a local privilege/DoS-class memory-safety bug, not a remote code execution issue despite the 'RCE' tag on the record.
An integer overflow in KVM's x86 Hyper-V synthetic timer emulation (stimer_start(), which computes a 100ns-tick deadline using ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))) allows a guest or userspace VMM to program a STIMERi deadline that wraps into the past, causing the vCPU to spin through an immediate hrtimer re-arm / KVM_REQ_HV_STIMER request cycle without ever disabling the timer. The result is a host CPU livelock that starves RCU grace-period kthreads and produces the RCU stall and eventual OOM condition reported by syzkaller. Exploitation requires a KVM x86 host running a guest with Hyper-V enlightenments and SynIC synthetic timers exposed, and control over the guest's WRMSR (HV_X64_MSR_STIMERi_CONFIG/COUNT) or KVM_SET_MSRS writes; the assessed vector is local, PR:L, availability-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, 7.1), with no public exploit identified at time of analysis and no CISA KEV listing.
A use-after-free race condition in the Linux kernel's s390 KVM guest-debug watchpoint code lets a local user who can control an IBM Z guest VM read or corrupt freed kernel memory. When a hardware watchpoint is imported via the KVM_SET_GUEST_DEBUG path, __import_wp_info() backs up guest memory with read_guest_abs() without holding kvm->srcu, so a concurrent memslot update can free the memslots array mid-read. Exploitation is s390-specific, requires local privileges over the VM/VMM (authenticated, PR:L per the assessed vector) and a narrow timing window, so reliability is limited; no public exploit code and no confirmed active exploitation were identified at time of analysis, and patch data indicates the vendor has released fixes.
Memory corruption on IBM Z (s390) KVM hosts running the Linux kernel is triggered when a channel-subsystem damage machine check (the CK bit) is reinjected into a guest, causing the host kernel to kfree() a stack variable. Exploitation requires an authenticated local actor with existing privileges on an s390 host that runs KVM guests (CVSS AV:L/PR:L) and depends on a hardware/host error condition that cannot be summoned on demand, which is reflected in the assessed AC:H and a scope-changed impact profile of low integrity and high availability impact rather than full host compromise. Vendor-released patches exist (stable 6.18.51, 7.2.5 and 7.3-rc1/mainline commits); no public exploit code and no confirmed active exploitation were identified at time of analysis.
A race condition in the Linux kernel's KVM s390 (IBM Z) keyop path lets a local user who already holds a KVM VM file descriptor cause gmap->asce to be read without the mmu_lock, potentially using a stale address-space-control element and corrupting memory. Exploitation requires s390 hardware, VM-fd access, and issuing KVM_S390_KEYOP concurrently with KVM_S390_VM_MEM_LIMIT_SIZE so that keyop reads asce while gmap_set_limit() mutates it under the write lock; it is timing-dependent, not remotely reachable, and no public exploit has been identified at time of analysis. The upstream fix has been merged and shipped in stable Linux 7.2.5 and 7.3-rc1, though an independent assessment rates real-world impact lower than the 7.8 base score by downgrading attack complexity to High and scope/confidentiality impact to None/low integrity, high availability.
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip an invalidation when the range ends at the last page or block of the TTBR1 VA space, because the exclusive end computation (base + size) wraps to zero. The faulty logic was introduced in Linux 6.16 and is fixed in 6.18.51, 7.2.5 and 7.3-rc1; hosts running unpatched kernels are exposed where a guest vCPU can drive trapped TLB-by-VA invalidations, while the IPA-invalidation path never suffered the rollover. The assessed vector is local (AV:L) with low privileges (PR:L) and high attack complexity (AC:H) because of the narrow address-layout precondition, with scope change and high availability impact; no public exploit code and no confirmed active exploitation (no CISA KEV entry) have been identified, and the provided reference CVSS of 9.3 overstates the practical risk relative to that assessment.
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed for a page-table mapping that another vCPU has just invalidated, so a guest can keep using a translation the host believes is gone, corrupting host state and potentially crashing the host. The flaw only affects arm64 hosts running KVM with nested virtualization (FEAT_NV2 / VNCR fixmap) enabled where an attacker already controls a guest with at least two concurrently executing vCPUs, and exploitation hinges on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another (one vCPU rewriting S1 page tables and issuing TLBI S1E2 while the other is mid-walk). Because the path is local-only and nested virtualization on arm64 is rarely deployed, the independent assessment rates the issue well below the vendor's CVSS 9.3 (assessed AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - high availability impact, low integrity impact, no confidentiality impact); no public exploit identified at time of analysis, and vendor patches are available in Linux 7.2.5, 6.18.51 and 7.3-rc1.
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations for an L1-supplied VNCR page in L0, allowing a guest with control of an L1 vCPU on an arm64 host to cross the guest-to-host boundary in a timing-sensitive way. Affected systems are those running kernel 6.16 or later with arm64 nested virtualization (FEAT_NV2 / VNCR page support) enabled and exposed to a guest; the flaw is a guest-to-host (L1-to-L0) issue, so exploitation requires guest-vCPU privileges and is local to the host, which contradicts the vendor's PR:N vector. Vendor-released patches exist in Linux 6.18.52, 7.2.5, and 7.3-rc1, and no public exploit code has been identified at time of analysis; the vendor's CVSS of 9.3 substantially overstates real-world risk given that nested virtualization is off by default and deployed on only a small subset of arm64 KVM hosts, and the missed-invalidation window is opportunistic and mapping-state dependent rather than deterministic.
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range because the decode_range_tlbi() helper omitted the required virtual-address sign-extension when it was reused for stage-1 TLBI handling, and the same helper can overflow physical-address bits when invoked for stage-2 invalidation. Only arm64 hosts running KVM are affected, and the attacker must already control a guest VM/vCPU able to issue range-based TLBI operations (low-privilege guest context, no user interaction, no network reachability); kernels from the 6.16 introduction through the fixes in 6.18.51, 7.2.5 and 7.3-rc1 are in scope. Exploitation results in stale or incorrectly scoped TLB entries on the host, with the assessed impact being availability loss (A:H) plus limited integrity impact (I:L) and no confidentiality impact; no public exploit identified at time of analysis.
A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a locally authenticated guest with vCPU-level access to trigger a dangling-pointer dereference against host kernel memory. The flaw requires an arm64 KVM host configured with GICv3 LPI/ITS support, where a concurrent irqfd cached-injection plus a guest ITS DISCARD can free an LPI that the pending-table save loop still holds via a stale xarray iterator pointer; the practical outcome is a host-side crash/denial of service with limited integrity impact rather than a clean, reliable privilege escalation, and exploitation depends on a tight timing window (assessed AV:L/AC:H/PR:L, S:C, C:N/I:L/A:H). Vendor patches are available in Linux 6.18.51, 7.2.5, and 7.3-rc1; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Host denial of service (with potential low integrity impact) in the Linux kernel's KVM/arm64 hypervisor allows a local attacker with guest execution privileges to trigger a TLB invalidation range overflow, corrupting hypervisor state. The flaw affects kernels approximately from 6.16 until the fixes in 6.18.51, 7.2.5, and 7.3-rc1, and requires the guest to issue TLB Invalidation by Range operations with an attacker-chosen virtual address. No public exploit code is identified at time of analysis.
Uninitialized stack memory in the Linux kernel's LoongArch KVM DMSINTC interrupt-injection path can let a local user who is able to create or control a KVM virtual machine - or code running inside a guest - have non-deterministic stack contents consumed while injecting a dynamic message-signaled interrupt. The vendor rates this 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), while our independent assessment keeps the local, low-privilege, scope-changing profile but lowers the impact components to C:L/I:L/A:L because the leaked data is not reliably attacker-controlled; the affected surface is limited to LoongArch hosts with KVM enabled and DMSINTC in use. Vendor fixes are available as upstream stable commits, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling KVM_MEM_LOG_DIRTY_PAGES for live migration) zeroes the slot's architecture-specific flags, so a slot previously marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can subsequently be mapped with PMD-sized entries; because the mapping path aligns the guest frame number and host page frame number independently, the guest can read or write the wrong host pages, giving a local attacker with access to the KVM VM file descriptor both confidentiality and integrity impact on the host (CVSS 8.8 vendor score, AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The independent assessment rates the attack complexity higher (AC:H) because exploitation requires a misaligned memslot plus a flags-only update, typically during live migration, and does not manifest for a static guest with aligned memslots; only the LoongArch architecture is affected. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV, though the tags classify the outcome as information disclosure and the successful corruption path is a memory-safety violation with high integrity impact.
Incorrect jump-offset calculation in the LoongArch BPF JIT of the Linux kernel can emit wrong tail-call branch targets, causing soft lockups (high availability impact) and, per the assessed vector, limited integrity impact, while confidentiality is unaffected. Affected are LoongArch (Loongson) systems running vulnerable kernel branches including the 6.1.x, 6.6.x, 6.12.x, 6.15.x, 6.16.x and 6.17 lines; exploitation requires local access plus the capability to load eBPF programs into the kernel (CAP_BPF or CAP_SYS_ADMIN, since unprivileged BPF is disabled by default), and only manifests when extra JIT passes occur, so it is not a deterministic single-request trigger. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the assessed severity is lower than the headline 7.8 because the flaw is architecture-specific, capability-gated and condition-dependent; vendor-released patches are available in 6.18.51, 7.2.5 and 7.3-rc1.
LoongArch Linux kernels overflow the fixed-size acpi_package_ids[] array while parsing the ACPI PPTT table, so a system whose firmware or hypervisor advertises more CPU packages (sockets) than the array can hold crashes during topology setup - the concrete case in the description being a LoongArch virt VM configured with one core per socket for up to 256 sockets. Affected builds are those before the fixed 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1 kernels; the flaw is reachable only on LoongArch, and the assessed precondition (per our independent analysis: AV:L/AC:H/PR:H, C:N/I:L/A:H) is control over the guest's ACPI topology rather than an ordinary unprivileged runtime action, with the practical outcome being a boot-time crash and memory corruption rather than remote code execution. No public exploit code was identified at the time of analysis and there is no CISA KEV record, so this is not confirmed as actively exploited; the vendor has released patches and the relevant upstream commits are public.
A race in the LoongArch rethook/kretprobe trampoline allows the per-CPU base register ($r21/$u0) to be restored with a stale value after a probed task is preempted and migrated to a different CPU, causing this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) to hit the wrong CPU's percpu area and ultimately corrupting scheduler and timer state. The result under heavy kretprobe load is scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and in the worst case a CPU parking in the idle loop with its timer never re-armed, i.e. a hard lockup and denial of service. Only LoongArch systems running a preemptible kernel with active kretprobes/rethook are affected, and arming kretprobes normally requires CAP_SYS_ADMIN/CAP_PERFMON (root-equivalent), so this is not reachable by unprivileged local users in default configurations; there is no public exploit identified at time of analysis and no confirmed active exploitation.
A preempt-count underflow in the Linux kernel's LoongArch Kprobes breakpoint handling allows a local, low-privileged user to issue the same break 11 instruction that userspace can generate, driving do_bp() into kprobe_singlestep_handler() with no active probe attached and calling preempt_enable_no_resched() without the matching preempt_disable() that kprobe_breakpoint_handler() would normally have performed. Only LoongArch (loongarch64) kernels with Kprobes enabled are affected-other architectures do not use this break-11 path-and the corrupted preempt state makes in_interrupt() return true until the task reschedules, which causes cgroup_sk_alloc() to attribute new sockets to the root cgroup and can thereby evade a BPF_CGROUP_INET_SOCK_CREATE policy bound to the task's own cgroup. No public exploit code identified at time of analysis and the flaw is not listed in CISA KEV; the vendor CVSS of 7.8 overstates practical severity, since independent assessment limits impact to integrity and availability (Low) with no confidentiality impact and notes the notable security consequence requires a BPF cgroup socket-create policy to be present.
A race condition in the Linux kernel HDMI-CEC core (drivers/media/cec) lets a local user who can open a CEC character device (/dev/cecN) free an in-flight transmit data structure while its delayed work item is still pending, corrupting kernel state and typically crashing the system. Exploitation requires a CEC-capable adapter, permission to the device node, and a signal delivered at a narrow timing window between cancel_delayed_work_sync() and the kthread's schedule_delayed_work(&data->work) in cec_transmit_done_ts() - no public exploit code has been identified at time of analysis, and the impact is a denial of service via the debugobjects 'free active' path rather than information disclosure. Vendor-released patches exist in stable trees (6.12.110, 6.18.51, 7.2.5) and in 7.3-rc1; the affected surface is effectively absent on headless servers and most virtualized deployments without CEC hardware.
An out-of-bounds write in the Linux kernel's HDMI-CEC driver for the Extron DA HD 4K Plus adapter (media: cec: extron-da-hd-4k-plus) lets a malicious or malfunctioning CEC device overflow the fixed-size msg.msg[] buffer, crashing the kernel and potentially corrupting kernel memory. Only hosts that have the extron-da-hd-4k-plus driver built and bound to an actual Extron DA HD 4K Plus CEC adapter are affected, and the malformed CEC message must arrive over the physically or adjacently attached CEC/serial link - there is no remote, over-the-network attack path against a default configuration. No public exploit code or in-the-wild exploitation has been identified at time of analysis, and the vendor's CVSS 8.8 (AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H) materially overstates real-world risk; our independent assessment is AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H, since the hardware is rare, the input channel is adjacent-only, and reliable escalation beyond a kernel crash is not demonstrated.
A race condition in the Linux kernel's HDMI-CEC subsystem (media: cec) lets a local user who can open a CEC adapter character device (/dev/cecN) and register as an exclusive follower race message delivery against follower mode changes or adapter release, reading the follower pointer without the adapter lock and creating a window that can corrupt kernel state or leak data. The assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) confirms this is a local, low-privilege issue requiring an actual CEC-capable adapter and precise timing, not the remote/unauthenticated scenario implied by the vendor's AV:A/PR:N score. No public exploit code and no confirmed active exploitation were identified at time of analysis; vendor patches are available across the maintained stable branches.
A heap out-of-bounds write in the Linux kernel's cx231xx USB video-capture driver allows a local, authenticated user (CVSS PR:L) who can open the device's V4L2 video and VBI nodes to corrupt kernel heap memory by resizing the device-wide frame geometry while a VBI stream is already running. The driver latches the VBI plane size at buffer-allocation time but recomputes the destination offset from the live dev->width and dev->norm on every URB completion, so an attacker can allocate a small VBI plane (small width or the NTSC standard), start VBI streaming, then enlarge dev->width via VIDIOC_S_FMT or switch dev->norm to PAL via VIDIOC_S_STD through the video node - the pre-patch code only checks the video queue (dev->vidq), not the VBI queue (dev->vbiq) - and have the device deliver a field-2 payload, causing cx231xx_do_vbi_copy() to memcpy() past the end of the smaller plane with an attacker-chosen offset and device-controlled contents. Vendor patches exist for Linux 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5 (mainline 7.3-rc1); no public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical impact is bounded by the requirement for physical or emulated cx231xx hardware plus a race against live URB completion (the independent assessment scores this AV:L/AC:H with C:L, below the vendor's 7.8 High).
A use-after-free in the Linux kernel's cx23885 media driver lets a local attacker with low privileges (CVSS PR:L) corrupt or crash the kernel by triggering a race during teardown of a Conexant CX23885-based NetUP DVB conditional-access (CI) device. The NetUP CI work item netup_read_ci_status() can still be pending or executing on the system workqueue when netup_ci_exit() frees the associated netup_ci_state, because the removal path calls free_irq() (which stops new interrupts but does not drain already-queued work) before the CI device is unregistered; the fix inserts cancel_work_sync() before dvb_ca_en50221_release() and kfree(). Practical risk is materially lower than the headline score: our assessment rates this AV:L/AC:H (the upstream vector is AV:L/AC:L) because exploitation requires the specific NetUP CI hardware and feature to be active plus a narrow removal-time race window (module unload, device unbind, or physical hot-unplug), and there is no public exploit identified at time of analysis. Vendor-released patches exist for the affected stable series (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, and 7.2.5/7.3-rc1).
A use-after-free in the Linux kernel's go7007 media driver allows a local user who can open the driver's ALSA capture PCM node to trigger memory corruption by keeping that PCM file open across a device removal or unbind event (for example, a USB unplug). The flaw is a lifetime mismatch: go7007_snd_remove() releases the v4l2_device reference immediately after snd_card_free_when_closed(), even though the ALSA card - and its PCM callbacks reaching struct go7007 through pcm->private_data - can stay alive until the last file is closed, so go7007_snd_hw_free() may run against an already-freed object. Per the independent assessment the vector is local-only (AV:L, PR:L, AC:H) with high availability impact and limited confidentiality/integrity impact, and successful, reliable triggering requires the specific WIS GO7007 hardware to be present and the teardown timing window to be won; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. Vendor-released patches are available in the stable branches listed below.
Use-after-free in the Linux kernel's ov02a10 MIPI CSI-2 sensor driver (media: i2c) can abort or destabilize driver probe on systems that physically include an OmniVision OV02A10 camera together with a firmware/device-tree description that binds that driver. The ov02a10_check_hwcfg() function calls fwnode_handle_put() on the parsed endpoint and then reads the optional 'ovti,mipi-clock-voltage' property through the same stale handle, while also letting the failure code from that optional property overwrite the function's return value, so probe can fail even when nothing else is wrong. Affected code ships from Linux 5.11 onward and is fixed in 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1; no public exploit has been identified at time of analysis, and although the vendor scored this 7.8 (HIGH), real-world risk is LOW because the path is reachable only in kernel probe context on specific sensor hardware and is not a remote or user-controllable trigger.
A teardown-order defect in the Linux kernel's ov7740 i2c camera-sensor driver causes a use-after-destroy and a double-free when the driver is unbound or the OmniVision OV7740 sensor is physically removed, panicking the kernel or otherwise taking the system down. Only systems that ship an OV7740 sensor with the CONFIG_VIDEO_OV7740 driver built or loaded are affected, so exposure is limited to specific embedded/SoC platforms. The flaw is local-only, cannot be triggered by an unprivileged process on a default configuration, and no public exploit identified at time of analysis; the vendor scores it 7.8, whereas our reassessment is lower (AV:L/AC:H/PR:L/UI:N/C:N/I:L/A:H) because the realistic impact is a crash rather than code execution or data disclosure - the accompanying 'Information Disclosure' tag is not supported by the assessed vector.
Double-decrementing the SCP device reference in the Linux kernel's MediaTek MDP3 (mtk-mdp3) media platform driver can free or unbalance a device object that the driver still uses, producing driver instability and potentially a use-after-free on systems that take the fallback SCP lookup path. The flaw is only reachable when scp_get() fails during mdp_probe() so that __get_pdev_by_id() runs; the reference taken by that fallback is dropped immediately, yet scp_put() is later called unconditionally from the probe error path and from mdp_video_device_release(). Exposure is confined to local presence on embedded MediaTek SoC hardware running the affected driver, the triggering scp_get() failure is a non-default condition rather than an attacker-controlled input path, and no public exploit code has been identified at time of analysis. Although NVD scores this 8.4, our independent assessment rates it CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H - high severity but low realistic risk.
The Linux kernel's sunxi-cir driver (Allwinner CIR/IR receiver, media/rc subsystem) fails to unregister the rc device when probe fails after rc_register_device() has already succeeded, leaving the registration and its resources behind. This is a local, low-severity driver lifecycle bug: the assessed vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, since the fault requires a genuine probe failure at IRQ lookup, IRQ request, or hardware initialization - conditions that are not attacker-controllable in a default configuration and generally need local privileged access (forced bind/unbind, resource exhaustion, or device-tree/IRQ faults) to induce. No public exploit code has been identified at time of analysis, and vendor-released fixes exist in stable kernels including 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, and 7.2.5.
Out-of-bounds array reads in the Linux kernel's Rockchip rkvdec stateless HEVC decoder allow a local user who can open the V4L2 mem2m decoder device node to trigger an unsigned integer underflow in short-term reference picture set (RPS) prediction, causing the driver to index far outside the calculated_rps_st_sets array. The flaw is reached by submitting an EXT_SPS_ST_RPS control with the INTER_REF_PIC_SET_PRED flag set and a crafted delta_idx_minus1 value that exceeds the current RPS index; the CVSS vector requires local access with low privileges (PR:L), so no third-party user interaction is needed but the attacker must already hold permissions on the decoder device. Impact is bounded to information disclosure and availability (the assessed vector is AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H), and it is confined to embedded Rockchip ARM platforms where the rkvdec driver is present and loaded; no public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV). The vendor-published CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk because exploitation demands specific hardware, driver availability, and a stateless decode session that raises attack complexity and limits the outcome to a memory read rather than code execution.
A missing error-path teardown in the Linux kernel's rtl2832_sdr SDR driver lets a local attacker with low privileges (PR:L) who can reach the V4L2/SDR device node for an RTL2832U-based USB dongle leak coherent DMA memory and trigger an out-of-bounds read/pass-garbage-pointer condition in USB URB cleanup. The defect only manifests when rtl2832_sdr_start_streaming() fails after allocation - realistically an induced -ENOMEM during alloc_stream_bufs()/alloc_urbs()/submit_urbs() - and is then followed by a second VIDIOC_STREAMON, which over-increments urbs_initialized past MAX_BULK_BUFS and causes rtl2832_sdr_free_urbs() to index beyond dev->urb_list[] before handing stale pointers to usb_free_urb(). The result is a resource leak and memory-corruption/denial-of-service condition rather than direct data theft, and our independent assessment scores this AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, materially below the vendor's 7.8 C:H/I:H/A:H rating; exploitation requires specific SDR hardware, the driver being loaded, and memory-pressure conditions, and there is no public exploit identified at time of analysis.
The Linux kernel's saa7164 media driver can leave a freed device structure dangling on the global saa7164_devlist when PCI BAR memory-region allocation fails during probe, because saa7164_dev_setup() adds the device to the list before calling get_resources() and never removes it on that error path; the probe cleanup then frees the device while the global list still points at it. Affected systems are those running the saa7164 driver against an SAA7164-based (NXP/Philips) TV capture card such as a Hauppauge HVR-22xx, and effectively any kernel built with CONFIG_VIDEO_SAA7164; the flaw was introduced with commit 443c1228d50518f3c550e1fef490a2c9d9246ce7 and is fixed in Linux 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5 (mainline 7.3-rc1). No public exploit has been identified at time of analysis (no CISA KEV entry, no published POC, no EPSS signal in the supplied data), and the vendor's CVSS 8.4 is not supported by our independent assessment, which rates the issue CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L and concludes real-world risk is LOW: the trigger is a hardware/probe-time resource failure rather than an attacker-controlled input, there is no remote vector, and no default configuration is affected.
Use-after-free in the Linux kernel's TI VPE/VIP media capture driver (media: ti: vpe) allows a locally authenticated attacker who can open and stream from a VIP /dev/videoN node to trigger memory corruption by racing stream teardown against outstanding interrupt work. The driver's VIP overflow recovery worker - armed from the hardirq handler when a FIFO overflow is detected - and the VPDMA list-complete path both continue to dereference stream, port, and device state after vip_release_stream() or free_stream() has freed those resources, because vip_stop_streaming() masks the per-list IRQs without synchronizing the hardirq handler or disabling recovery_work. Exploitation requires local access plus the ability to induce a FIFO overflow and win a tight timing window against file release or unbind/remove, so our independent assessment rates this AC:H with limited confidentiality and integrity impact but high availability impact (NVD scores it 7.8 AV:L/AC:L/PR:L). No public exploit code was identified at time of analysis, and the flaw is hardware-specific to TI Davinci/OMAP/AM-class SoCs with VIP capture hardware.
Out-of-bounds array access in the Linux kernel V4L2 control framework for stateless HEVC decoders lets a local user who can write to a V4L2 device node (/dev/video*) supply HEVC SPS short-term and long-term reference picture set counts that exceed the HEVC limits of 64 ST RPS sets and 32 LT references, so a decoder driver that trusts those counts can index past the EXT SPS dynamic arrays. The published CVSS vector rates this as 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), whereas our independent assessment scores it lower (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) because the flaw only manifests when a stateless HEVC decoder driver consumes the attacker-supplied counts without performing its own bounds validation; there is no public exploit identified at time of analysis and no CISA KEV entry. Vendor-released fixes are available in Linux 7.2.5 and 7.3-rc1.
Double-free in the Linux kernel's legacy zoran V4L2 media driver on teardown allows a local user who can trigger device/driver removal to kfree() the same registered video_device twice, crashing the kernel or corrupting kernel memory. Only systems where the zoran driver is bound to real Zoran ZR36057/ZR36067-based PCI MJPEG framegrabber hardware (Buz, DC10, LML33-class cards) are affected, and the flaw is reachable only through teardown paths such as module unload, PCI unbind/removal, or driver shutdown - not through normal runtime device I/O and not remotely. Vendor patches are available across maintained stable branches (6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5, and 7.3-rc1); exploitation requires the local authenticated context indicated by the CVSS vector (PR:L), and no public exploit code or confirmed active exploitation was identified at time of analysis. The practical impact is bounded to local denial of service because the affected hardware is obsolete and rarely deployed and the outcome is a crash rather than a controlled memory write.
Kernel crash (NULL pointer dereference) in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver, in the EDIF (encrypted FC / FC security) RX security-association delete check, allowing a host using that driver and feature to be taken down by a kernel oops in interrupt context. Only systems with a QLogic FC adapter, the qla2xxx driver loaded, and EDIF/FC-SP encryption in use are exposed; the assessed vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H (integrity and confidentiality unaffected, availability high), which is considerably narrower than the vendor's published AV:N/AC:L/PR:N rating and reflects that triggering the fault depends on a driver-internal abort/return timing race rather than remotely supplied network input. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor patches are already released for the affected stable branches.
A race condition in the Linux kernel's qla2xxx QLogic Fibre Channel driver allows a concurrent vport deallocation to free an NPIV virtual port while the format-1 report-ID-acquisition path still dereferences it, producing a use-after-free. The flaw is reachable only on systems that run a qla2xxx-driven QLogic FC HBA with NPIV virtual ports configured and that grant an attacker the local privilege needed to create and tear down virtual ports; the window is narrow (AC:H) and no attacker-controlled network input reaches the freed pointer, so the realistic outcome is a kernel crash or denial of service rather than controlled memory corruption. An independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H, notably lower than the published AV:N/PR:N vector, and no public exploit has been identified at time of analysis.
Repeated command aborts in the Linux kernel's qla2xxx (QLogic Fibre Channel) driver can reinitialize an already-queued work item, corrupting workqueue list state and leading to host crashes, hangs, or a looping worker - a denial-of-service condition on systems using NVMe over Fibre Channel. Affected code exists from the introduction commit e473b3074104ee09227cfbba5f872e3ea15dd280 (reported as Linux 4.17) onward, and fixes are available in stable releases 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1. No public exploit code has been identified at time of analysis, and the bug is a driver-internal timing race rather than an attacker-invokable primitive: triggering requires a host with a qla2xxx HBA actively handling NVMe-FC FCP or LS I/O where two aborts for the same command race (for example, concurrent transport teardown and a timeout-driven abort), so our assessment rates it substantially lower than the vendor's headline CVSS of 8.8 (AV:A/PR:N) - a local, high-complexity race with no confidentiality impact.
Concurrent NVMe-FC I/O submission in the Linux kernel's qla2xxx QLogic Fibre Channel driver can corrupt the hardware request-ring producer state, producing duplicated or dropped commands. The defect affects hosts running the qla2xxx driver with a QLogic FC HBA configured for NVMe-over-FC that uses ha->base_qpair; qla_nvme_ls_reject_iocb() advances the ring and rings the request-in doorbell via __qla2x00_alloc_iocbs() and qla2x00_start_iocbs() (both of which assume hardware_lock is held) but two of its callers, qla_nvme_xmt_ls_rsp() and qla2xxx_process_purls_pkt(), invoke it without holding qp_lock_ptr. Our independent assessment rates this as a local, race-window-dependent integrity/availability issue (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L), materially lower than the vendor's NVD score of 9.8, because the reject events are driven by Fibre Channel fabric/transport conditions rather than attacker-supplied input and require precise concurrency with normal base-ring submission; there is no public exploit identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV).
Memory corruption and kernel crashes in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver arise from an integer truncation when the driver derives its request/response queue counts from the adapter's advertised MSI-X vector count. Affected systems are those running the CONFIG_SCSI_QLA_FC driver and bound to a QLogic FC HBA that reports a boundary MSI-X count (257 vectors, which truncates to zero in the u8 queue-count fields, or exactly 1), after which qla2x00_alloc_queues() obtains ZERO_SIZE_PTR from kzalloc_objs(struct req_que *, 0) and then dereferences it via ha->req_q_map[0]; target-mode configurations can additionally underflow max_req_queues from 0 to 255. Exploitation requires physical or firmware-level control of a PCI/FC device (per our independent assessment of CVSS:3.1/AV:P/AC:H/PR:N/UI:N, C:N/I:L/A:H) rather than any network or unprivileged-user input, and there is no public exploit identified at time of analysis. Vendor patches are available in the referenced stable tree commits.
A use-after-free read in the Linux kernel's qla2xxx SCSI driver allows a local low-privilege (authenticated) user on a host with a QLogic cs84xx-capable Fibre Channel HBA to dereference freed memory by reading the 84xx_fw_version sysfs attribute while the adapter is being torn down. The race is bounded to the teardown window between qla84xx_put_chip() freeing ha->cs84xx and scsi_remove_host() draining the sysfs show handler, and since the dereference in qla24xx_84xx_fw_version_show() is read-only the realistic impact is an information leak or kernel crash rather than controlled corruption, meaning the vendor CVSS of 7.8 overstates real risk for this narrow, hardware-dependent timing bug. There is no public exploit identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); vendor patches are available in the stable kernel releases listed in remediation.
Wild-pointer dereference in the Linux kernel's qla2xxx QLogic Fibre Channel HBA driver lets an unexpected STATUS_TYPE completion IOCB reach a SCSI-only fast path, where the srb union is reinterpreted so sp->u.scmd.cmd reads as a non-NULL garbage pointer and is dereferenced. Only hosts running the qla2xxx driver with a physical QLogic FC HBA are exposed, and only when the adapter firmware or FC fabric delivers a mis-typed status IOCB that coincides with a live non-SCSI outstanding handle; the assessed vector is CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H, so the realistic outcome is a kernel crash rather than reliable code execution. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor patches are available for all maintained stable branches.
Use-after-free in the Linux kernel qla2xxx QLogic Fibre Channel SCSI driver lets a local user who can trigger queue-pair teardown reach freed request-queue memory through a late response-queue interrupt. On hosts with a QLogic FC HBA using MSI-X multiqueue qpairs, qla2xxx_delete_qpair() frees the request queue via qla25xx_free_req_que() before the response-queue IRQ is released in qla25xx_free_rsp_que(), so a response interrupt firing in that window causes qla2xxx_msix_rsp_q() to queue qpair->q_work and qla_do_work() -> qla24xx_process_response_queue() to dereference the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path). The result is full memory corruption with high confidentiality, integrity, and availability impact, but exploitation requires winning a narrow local race during qpair deletion; no public exploit code or active exploitation was identified at time of analysis, and vendor patches are available.
A double-completion race in the Linux kernel's qla2xxx QLogic Fibre Channel driver can cause a use-after-free write into a freed on-stack completion structure, leading to kernel memory corruption, a kernel crash, or potential local privilege escalation. Only hosts with a QLogic FC HBA and the qla2xxx driver loaded are affected, and the fault requires qla24xx_async_abort_cmd() to fail while the response ISR completes the same SRB handle at almost the same instant the async IOCB timeout handler re-scans outstanding_cmds[], so the attacker must win a very narrow concurrency window - local access only and no network reachability. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor patches are available in the stable releases 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and the NVD score of 9.8 (AV:N/AC:L/PR:N) should not drive prioritization given the assessed vector of AV:L/AC:H/PR:L/UI:N.
An out-of-bounds read in the Linux kernel's qla2xxx Fibre Channel host bus adapter driver (qla2x00_status_entry()) allows a hostile, compromised, or malfunctioning FC storage target to leak adjacent response-ring or heap memory into the local SCSI sense buffer of a host using a QLogic 24xx/29xx-class HBA. The bug is an unsigned integer underflow: the target-supplied 32-bit sf.rsp_data_len (rsp_info_len) is subtracted from the IOCB data-area size (par_sense_len, 28 bytes on 24xx and 60 bytes on 29xx) without a clamp, so oversized values wrap par_sense_len to a huge number and advance sense_data past its bounds before the capped memcpy in qla2x00_handle_sense(). Vendor-released patches are available in stable branches 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and 7.3-rc1, and no public exploit has been identified at time of analysis; the vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:H) substantially overstates real-world risk, since the attacker must already occupy a trusted target role on the Fibre Channel fabric and the disclosed memory is bounded to at most SCSI_SENSE_BUFFERSIZE of local ring/heap data.
Concurrent host_map btree corruption can occur in the Linux kernel's qla2xxx QLogic Fibre Channel driver because the format-1 branch of qla24xx_report_id_acquisition() releases vport_slock before invoking qla_update_host_map()/qla_update_vp_map(), which mutates ha->host_map without the serialization the function contract requires. Only systems running the qla2xxx driver with a QLogic FC HBA and NPIV virtual ports configured (a privileged local configuration) exercise this code path, and triggering it depends on winning a narrow, non-deterministic timing race against another host_map update. The result is kernel-internal data-structure corruption rather than direct data theft; no public exploit code has been identified and the issue is not confirmed as actively exploited (no CISA KEV).
A folio reference-count imbalance in the Linux kernel's f2fs filesystem lets a local user who can drive the redirty_blocks() path over-decrement a pinned folio when read_cache_folio() fails before any folio is pinned and readahead has already cached that same folio, after which drop_caches or reclaim can emit "BUG: Bad page state" and corrupt kernel memory state. Only kernels that include the folio-conversion commit 5951fee46bef are affected, i.e. Linux 6.16 through the fixed releases 6.18.51, 7.2.5 and 7.3-rc1. Exploitation requires local access with low privileges (CVSS:3.1/AV:L/PR:L) and is gated on a non-deterministic failure-plus-readahead race, so reliability is poor (AC:H); the independent assessment rates confidentiality impact as none with limited integrity and high availability impact, and no public exploit has been identified at time of analysis.
A use-after-put race in the Linux kernel's f2fs filesystem during large-folio invalidation allows a local low-privileged attacker who can concurrently drive a truncate or folio split against f2fs_get_read_data_folio() to leave stale xarray slots and corrupted page state in the page cache, resulting in livelocks, bad page statistics, and possible memory corruption. Only kernels built with f2fs large/compound folio support are affected - the flaw was introduced on the v6.18/7.0 development line (commit 05e65c14ea59a401cec4284e9d612f9d5dc1b3f8 and later) and is fixed in the vendor-released 7.2.5 stable update and 7.3-rc1. The vendor rates this 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), but independent assessment downgrades it to AC:H/C:L because a narrow timing window must be won and the outcome is memory corruption or denial of service rather than reliable code execution; no public exploit identified at time of analysis.
Incorrect node-block validation in the Linux kernel's f2fs filesystem causes f2fs_sanity_check_node_footer() to be invoked with the wrong folio index, so the sanity check re-validates the same nid instead of the node actually being read, allowing a local user who is permitted to mount a crafted or corrupted f2fs volume to bypass the intended footer validation and trigger out-of-range metadata access - most plausibly a kernel crash or denial of service. The affected code path is reachable only when an attacker-influenced f2fs image is mounted (CVSS AV:L, PR:L), and exploitation requires supplying malicious on-disk metadata, which raises real attack complexity. Vendor patches are available in stable releases 6.18.51 and 7.2.5 (plus mainline 7.3-rc1); no public exploit identified at time of analysis, and the CNA's boilerplate 7.8 HIGH score (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) overstates the issue relative to the assessed vector AV:L/AC:H/PR:L/UI:N/C:L/I:L/A:H, whose dominant impact is availability loss.