Linux
Monthly
Memory hotplug removal in the Linux kernel leaks device references because `find_memory_block()` acquires a kobject reference inside `remove_memory_blocks_and_altmaps()` that is never released, allowing the reference count to accumulate unchecked across repeated memory block removal cycles. Systems with memory hotplug support - including virtual machines using ACPI memory balloon drivers and bare-metal servers with hot-pluggable DIMM slots - are affected across multiple stable kernel branches, with patches confirmed for 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and exploitation probability is extremely low (EPSS 0.16%), though the availability impact is rated high: leaked references accumulated over repeated hotplug cycles can eventually precipitate a kernel panic.
Memory exhaustion in the Linux kernel WWAN IOSM driver allows a local low-privileged attacker to deplete kernel memory by repeatedly triggering error paths in `ipc_imem_init()` where memory allocated by `ipc_protocol_init()` is never released. Affected systems running kernel versions from 5.14 through the unpatched branches of 5.15, 6.1, 6.6, 6.12, 6.18, 7.0, and pre-7.1 with Intel WWAN IOSM modem hardware loaded are vulnerable to availability-impact memory exhaustion. No public exploit exists and EPSS probability sits at 0.16% (6th percentile), indicating negligible real-world exploitation likelihood; however, patched stable releases are available across all major kernel branches.
Kernel self-deadlock in the Linux phonet/pep subsystem allows a local low-privilege attacker to crash affected systems by triggering an inconsistent bottom-half (BH) lock state on a child PEP socket. The flaw exists from kernel 2.6.28 through unpatched stable branches up to 7.x, and is reachable only when the Phonet protocol module is active. No public exploit or active exploitation is confirmed; EPSS is 0.16% (6th percentile), consistent with the niche deployment context.
CPU exhaustion in the Linux kernel's cfg80211 WiFi subsystem allows an attacker within radio range to trigger a runaway loop in cfg80211_merge_profile() by broadcasting a specially crafted Multi-BSSID beacon frame, consuming up to 2 milliseconds of kernel CPU time per beacon received. Devices running Linux 5.2 and later with cfg80211-based WiFi drivers are affected across eight stable kernel branches, from 5.10.x through 7.0.x, until patched. No public exploit has been identified at time of analysis, and EPSS probability is 0.17% at the 7th percentile, indicating no observed active exploitation.
Invalid cleanup in the Linux kernel's tracing_map subsystem causes a kernel panic when memory allocation fails during element initialization. Specifically, the error path in tracing_map_elt_alloc() incorrectly invokes map->ops->elt_free() on uninitialized data when elt_alloc() was never successfully called, producing an invalid memory operation that crashes the kernel. This affects all kernel branches from 4.17 through the respective fixed stable releases. No public exploit exists and EPSS is 0.16% (6th percentile), but any local low-privileged user with access to the tracing subsystem who can induce allocation failures can trigger a denial of service.
Runtime PM reference count leak in the Linux kernel's Tegra I2C driver permanently prevents the affected I2C controller from entering runtime suspend when tegra_i2c_mutex_lock() returns an error. The asymmetric acquire-without-release of pm_runtime_get_sync() causes device power management to malfunction on NVIDIA Tegra SoC hardware, covering Linux 7.0 through pre-7.0.11 and pre-7.1. No public exploit exists and EPSS at 0.14% (4th percentile) reflects minimal exploitation interest; this is a stability and power management correctness defect rather than a security attack vector in the conventional sense.
NULL pointer dereference in the Linux kernel's SPI QUP (Qualcomm Universal Peripheral) driver causes a local denial-of-service condition affecting Qualcomm SoC-based Linux systems. When DMA setup fails during driver probe, the fallback to PIO mode leaves DMA channel pointers in a stale error state rather than clearing them to NULL; a subsequent probe failure or driver unbind then dereferences those error pointers, triggering a kernel panic. Patches are available across all active stable branches (5.10.259, 5.15.210, 6.1.176, 6.6.142, 6.12.92, 6.18.34, 7.0.11, 7.1); no public exploit has been identified and EPSS is at the 6th percentile, indicating negligible exploitation probability at this time.
Error pointer dereference in the Linux kernel ep93xx SPI driver causes kernel panic (denial of service) under specific driver lifecycle conditions on Cirrus Logic EP93xx ARM SoC hardware. When DMA channel setup fails during driver probe and falls back to PIO mode, the driver fails to clear the DMA channel pointers; any subsequent probe error or driver unbind then dereferences those stale error pointers, triggering a kernel oops or panic. No public exploit exists and EPSS of 0.16% (5th percentile) reflects negligible real-world exploitation probability - this is a targeted stability fix for a niche embedded platform.
Error pointer dereference in the Linux kernel's spi-sprd driver causes local denial of service on systems equipped with Spreadtrum (SPRD) SoC hardware. When DMA setup fails during driver probe and the driver falls back to PIO mode, a subsequent late probe error triggers a cleanup path that does not check the dma.enabled flag before attempting to release DMA channels - resulting in an error pointer dereference or double-channel-release and consequent kernel panic. No public exploit exists and EPSS sits at 0.17% (6th percentile), reflecting the highly hardware-specific nature of this flaw. Vendor-released patches are confirmed across multiple Linux stable branches.
Crash kernel panic in Linux kernel's KHO (Kexec Handover) subsystem causes kdump capture to fail due to a missing crash-kernel guard in kho_fill_kimage(). Systems configured with both KHO and a crash kernel (kdump) are affected: when a kernel crash transfers control to the crash kernel, KHO metadata pointing outside the reserved crash region triggers an invalid phys_to_virt() translation in kho_memory_init(), crashing the crash kernel itself and defeating the crash dump mechanism. No public exploit exists and EPSS at 0.16% (6th percentile) reflects appropriately low exploitation probability given the local-only, configuration-dependent nature of the flaw.
NULL pointer dereference in the Linux kernel's ARM Firmware Framework for Armv8-A (arm_ffa) bus driver allows a local actor with kernel module loading rights to crash the host system. The bus match callback unconditionally dereferences the id_table pointer of any registering FF-A client driver; a driver that omits id_table triggers an immediate kernel panic, producing a denial-of-service condition. EPSS at 0.17% (6th percentile) and absence from the CISA KEV catalog indicate no public exploit and negligible observed exploitation activity.
Early boot initialization on ARM Integrator/CP hardware in the Linux kernel triggers a NULL pointer dereference by invoking memory allocation routines before the memory management subsystem is operational, causing a kernel panic that renders affected systems unbootable. The regression was introduced by commit bdb249fce9ad4 and affects all Linux stable branches from that point through patched releases (5.10.258, 5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, 7.1). No public exploit exists, CISA KEV does not list this vulnerability, and EPSS sits at 0.17% (7th percentile), reflecting the narrowly scoped, hardware-specific nature of the defect.
Sleep-in-atomic-context denial of service in the Linux kernel btrfs filesystem driver allows a local low-privileged user to crash the system by triggering file sync operations while kernel tracing is active. The btrfs_sync_file trace event erroneously calls dput() - a function that may sleep - within an atomic context where sleeping is forbidden, producing a kernel BUG splat and potential panic. No active exploitation has been identified, EPSS is 0.16% (6th percentile), and the vulnerability requires a non-default kernel tracing configuration to be exploitable, substantially limiting real-world exposure.
Kernel panic in the Linux kernel's kprobes self-test module (test_kprobes) allows a local attacker or privileged user with debugfs write access to crash the kernel by triggering the KUnit kprobes test suite twice in succession. The root cause is that static kprobe and kretprobe variables retain stale address and flag data after unregister_kprobe, causing re-registration to fail with -EINVAL and subsequently triggering a kernel paging fault on the second test run. No public exploit is identified at time of analysis; EPSS at the 6th percentile and absence from CISA KEV confirm this as low-priority in production contexts.
Resource leak in the Texas Instruments ICSSG PRUETH Ethernet driver causes a device-tree node reference count to go unreleased on a specific probe error path, degrading kernel resource availability. Affected kernels from commit 511f6c1ae093c7045742299d29eba71925709a71 onward, prior to stable backports landing in 6.18.34, 7.0.11, and 7.1, are at risk only on hardware platforms carrying TI ICSSG silicon. EPSS sits at 0.17% (6th percentile) and no public exploit or CISA KEV entry exists, positioning this as a maintenance-tier stability fix rather than an active threat.
Incorrect zero_point calculation in the Linux kernel netfs layer's netfs_release_folio() function causes short reads and application-level I/O failures on network filesystem mounts when local pagecache size (i_size) exceeds the server-reported file size (remote_i_size). The bug affects local users on systems mounting CIFS or other netfs-backed shares with caching enabled, and was reproducible via a specific sequence of truncate, write, mapread, and copy_range operations on CIFS with the default cache option. No active exploitation is confirmed (not in CISA KEV), EPSS is 0.15% at the 5th percentile, and patches are confirmed available for kernel stable branches 7.0.11 and 7.1.
Incorrect dirty-region bookkeeping in the Linux kernel netfs subsystem (netfs_invalidate_folio) causes a local denial-of-service condition when streaming-write folios are partially invalidated. The bug is present in kernels from commit cce6bfa6ca0e through multiple stable branches and is fixed in 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit or active exploitation has been identified; EPSS sits at 0.17% (6th percentile), reflecting very low real-world exploitation probability despite the kernel's ubiquitous deployment.
Incorrect writeback state management in the Linux kernel's netfs and AFS subsystems allows a local low-privileged user on an AFS-mounted system to cause filesystem availability degradation. When netfs_write_single() or afs_single_writepages() skips a write due to lock contention under asynchronous writeback (WB_SYNC_NONE), the affected inode loses its dirty mark without the write being rescheduled, meaning data may never be flushed to the AFS server. No public exploit has been identified and the EPSS score of 0.17% at the 6th percentile reflects very low exploitation probability; patched versions are confirmed available across multiple stable kernel branches.
Memory leak in the Linux kernel's ath11k WiFi driver (Qualcomm Atheros 802.11ax) allows a local low-privileged user to exhaust kernel memory by triggering error paths in two WMI Wake-on-WLAN (WOW) command functions that fail to free associated socket buffers (skb) on failure. Patched across all active stable kernel branches (5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, and mainline 7.1). No active exploitation has been identified, with EPSS at 0.17% (7th percentile), consistent with a routine driver memory management fix rather than a weaponizable vulnerability.
Reference leak in the Linux kernel's Qualcomm Adreno a6xx GPU driver (drm/msm/adreno) can cause kernel memory reference exhaustion on affected hardware, leading to system instability or a kernel panic. The flaw in a6xx_gpu_init() allows of_parse_phandle() node references to escape release on multiple early error return paths, bypassing the required of_node_put() cleanup. No active exploitation has been identified; EPSS is 0.17% (6th percentile), no KEV listing exists, and impact is limited to availability on hardware-specific Linux deployments.
DMA mapping failures in the Linux kernel's dma-mapping subsystem crash device driver probes on ARM64 systems with SPARSEMEM due to an incorrect pfn_valid() precondition check in dma_map_resource(). On Raspberry Pi 4 and similar ARM64/SPARSEMEM platforms, MMIO registers whose physical addresses share a 128MB sparsemem section with RAM are misidentified as RAM, causing WARN_ON_ONCE to fire and dma_map_resource() to return DMA_MAPPING_ERROR, breaking peripheral initialization (e.g., spi_bcm2835 SPI controller). No public exploit identified at time of analysis; this is a functional kernel regression with local availability impact rather than a remotely exploitable security flaw.
The pds_core driver in the Linux kernel leaks debugfs dentry references on every firmware reset recovery due to missing dput() calls after debugfs_lookup(), and can crash the kernel when CONFIG_DEBUG_FS is disabled because ERR_PTR(-ENODEV) is not properly distinguished from NULL. A local user with standard privileges on a system hosting AMD/Pensando DPU hardware can trigger repeated firmware reset cycles to exhaust kernel memory, causing denial of service; on kernels with CONFIG_DEBUG_FS=n, a single reset recovery call can immediately crash the system via an invalid dput() on an error pointer. No public exploit exists and EPSS is 0.18% (7th percentile), but patches are available across multiple stable branches.
Resource exhaustion in the Linux kernel erofs filesystem driver allows a local low-privileged attacker to leak folio references via error paths in erofs_init_inode_xattrs(), potentially causing kernel memory resource exhaustion or denial of service. Affected systems are those running Linux kernel versions from 5.17 through the fix commits, where erofs filesystems with extended attributes (xattrs) are mounted. No public exploit code exists and the vulnerability is absent from CISA KEV; vendor-released patches are available in stable branches targeting 7.0.11 and 7.1.
Memory leak in the Linux kernel's btmtk (MediaTek Bluetooth USB) driver allows a local low-privileged user to exhaust kernel memory, causing denial of service. The vulnerability affects systems running Linux kernel from commit a1c49c434e15050b5dafe3b6f5cc732d4f02d657 onward, with patches confirmed in stable releases 6.6.142, 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and no active exploitation has been confirmed; an EPSS of 0.18% at the 7th percentile places this firmly in low-priority territory for most organizations.
Permanent battery hardware damage on Uniwell-based laptops can be triggered via the platform/x86/uniwill-laptop kernel driver by enabling the battery charging limit through the 'force' module parameter. Affected hardware is limited to older Uniwell OEM models manufactured around 2020 where the charging limit circuitry is incompatible with the feature and causes irreversible battery degradation. No public exploit exists and EPSS stands at 0.16% (6th percentile), reflecting the narrow hardware and configuration prerequisites; however, the impact is severe and permanent - affected batteries cannot be recovered once damaged.
Kernel memory exhaustion via ksmbd's POSIX-to-DACL ACL conversion causes a reliable denial-of-service against Linux SMB servers. Commit 299f962c0b02 introduced `check_add_overflow()` guards in `set_posix_acl_entries_dacl()` to prevent u16 DACL size wrap-around, but the resulting `break` statements bypass the `kfree(sid)` cleanup calls, leaking one or more `struct smb_sid` kernel heap allocations each time the overflow check fires. EPSS is 0.18% (8th percentile), no KEV listing exists, and no public exploit code has been identified, but the leak is deterministic and repeatable on every DACL request against a file with sufficient POSIX ACL entries, making memory exhaustion straightforward for any attacker with SMB access to the server.
Stack buffer overflow in the Linux kernel adm1266 PMBus hardware monitor driver allows a local low-privileged user to crash the kernel on systems equipped with an Analog Devices ADM1266 power sequencer chip. The vulnerable function allocates a 5-byte stack buffer but passes it to i2c_smbus_read_block_data(), which performs an unchecked memcpy of up to 32 bytes (I2C_SMBUS_BLOCK_MAX) before any length validation - overflowing the stack and causing a denial of service. No public exploit code exists and EPSS at 0.18% (7th percentile) confirms limited exploitation interest; patched versions are available across all active stable kernel branches.
Spurious kernel WARN() triggers in Linux kernel mm/memory.c during process teardown when NVIDIA UVM or HMM-capable GPU drivers are present alongside private file-backed mappings containing migrated anonymous folios. The unmap path incorrectly uses vma_is_anonymous() rather than folio_test_anon() to gate device-private/exclusive page handling, producing false-positive kernel warnings (not panics) during munmap or process exit in affected configurations. No public exploit has been identified at time of analysis; EPSS at 0.17% (7th percentile) reflects the narrow triggering conditions required and the non-weaponizable nature of a spurious WARN().
Stale ARM64 Memory Tagging Extension (MTE) tag exposure in the Linux kernel's huge zero folio allocation path undermines the init_on_free security guarantee on AArch64 systems. When the kernel is booted with init_on_free=1 and a 2MB anonymous mapping triggers the huge zero folio path (mapped as a PMD-special entry), the __GFP_ZEROTAGS flag causes post_alloc_hook() to skip tag memory clearing while content zeroing was already handled at free time - leaving whatever allocation tags were previously set accessible to user space. No public exploit has been identified at time of analysis, and EPSS stands at 0.17% (6th percentile), consistent with the narrow architectural and configuration prerequisites required to trigger the flaw.
Spinlock leak in the Linux kernel's huge page device migration subsystem causes a local denial of service via deadlock. A low-privileged local user who can trigger the `migrate_vma_insert_huge_pmd_page` code path while inducing `check_stable_address_space()` to fail will leave the PMD spinlock permanently held, deadlocking any subsequent thread that attempts to acquire it. No public exploit has been identified and EPSS at 0.17% (7th percentile) reflects negligible real-world exploitation probability; the vulnerability is not in CISA KEV.
Null pointer dereference in the Linux kernel's Bluetooth ISO reassembly path allows any Bluetooth broadcaster within radio range to crash a victim Linux host by transmitting an ISO_END PDU without a preceding ISO_START on a BIS (Broadcast Isochronous Stream) connection. Affected kernels span all stable branches from the ISO introduction commit (ccf74f2390d60a2f9a75ef496d2564abb478f46a) through fixed releases 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code or CISA KEV listing exists at time of analysis; EPSS is 0.18% (8th percentile), reflecting low current exploitation probability despite the unauthenticated wireless trigger available to BIS attackers.
Kernel stack address disclosure in the Linux kernel's Bluetooth L2CAP subsystem leaks 8 bytes of kernel virtual address space to a paired Bluetooth peer whenever a local user triggers an L2CAP Enhanced Credit-Based Reconfigure (ECRED) request. The flaw was introduced by commit 1c08108f3014 when DEFINE_RAW_FLEX() converted the on-stack PDU struct but left l2cap_send_cmd() receiving the local pointer's stack storage address and sizeof(pointer) instead of the struct address and struct size. As a result, the ECRED reconfigure feature has been functionally broken for local initiators since that commit, and every reconfigure attempt passively leaks a KASLR-randomized kernel stack address to the Bluetooth peer, potentially aiding ASLR/KASLR bypass. No public exploit is identified at time of analysis, and the EPSS score of 0.18% (7th percentile) reflects low automated exploitation probability.
NULL pointer dereference in the Linux kernel's ethtool PHY subsystem allows a local low-privileged user to crash the kernel and cause a denial of service. The flaw in `phy_prepare_data()` fails to check return values from `kstrdup()` for the strings `name`, `drvname`, `upstream_sfp_name`, and `downstream_sfp_name`; when allocation fails and returns NULL, `phy_reply_size()` subsequently calls `strlen()` unconditionally on the NULL pointer, triggering a kernel oops and system panic. No public exploit code has been identified and EPSS stands at 0.17% (6th percentile), but the availability impact is total - a kernel panic - making this a standard patching priority for any multi-user or shared Linux environment.
CPU pinning denial-of-service in the Linux kernel L2TP subsystem allows an unprivileged local user to wedge a host CPU indefinitely by exploiting an RCU list management mismatch in l2tp_session_unhash(). By creating a user network namespace (unshare -Urn) to obtain CAP_NET_ADMIN and then racing L2TP_CMD_SESSION_CREATE, L2TP_CMD_SESSION_DELETE, and L2TP_CMD_SESSION_GET against the same tunnel, an attacker causes a session list walker to enter an infinite loop with BH and preemption disabled - stalling RCU grace periods system-wide and rendering the thread unkillable via SIGKILL. No public exploit has been identified at time of analysis; EPSS at 0.17% (6th percentile) indicates low automated exploitation probability and no CISA KEV listing.
Memory leak in the Linux kernel igc driver's Frame Preemption (FPE) implementation affects systems with Intel I225/I226 Ethernet controllers running kernel versions from commit 5422570c0010bb968738f9256eb2bf83e79b4d63 onward. The function igc_fpe_xmit_smd_frame() allocates a socket buffer for SMD frame transmission but fails to release it when igc_fpe_init_tx_descriptor() returns an error, confirmed by kernel SLAB unreferenced-object traces showing 224-byte skb allocations going unfreed. No public exploit has been identified and EPSS stands at 0.17%, indicating negligible broad exploitation interest; the practical exposure is limited to TSN-capable deployments with FPE explicitly enabled.
NULL pointer dereference in the Linux kernel's PCM512x ASoC audio codec driver crashes the kernel when a local low-privileged user writes to the overclocking mixer kcontrol. The driver's pcm512x_overclock_xxx_put() handler incorrectly invokes snd_soc_dapm_kcontrol_to_dapm() on a standard mixer kcontrol - an accessor only valid for DAPM kcontrols - returning NULL and triggering a kernel panic. No public exploit has been identified and EPSS stands at 0.16% (6th percentile), reflecting low exploitation likelihood; impact is confined to denial of service on systems with PCM512x audio hardware.
KVM arm64 vGIC in the Linux kernel leaks kernel memory when vCPU initialization fails, enabling a local attacker with VM-creation privileges to exhaust host memory and cause denial of service. The defect is a missing cleanup call in the kvm_vgic_vcpu_init() error path: private IRQs allocated prior to a redistributor iodev registration failure are never freed before the failed vCPU structure is released. No public exploit has been identified at time of analysis; an EPSS score of 0.17% (6th percentile) reflects low opportunistic exploitation probability, and the flaw is not listed in CISA KEV.
Out-of-bounds heap read in the Linux kernel's fwctl pds driver allows a local low-privileged user to crash the kernel by submitting an undersized RPC buffer, resulting in a denial of service. Affected kernel versions include Linux 6.15 and all stable trees prior to 6.18.34, 7.0.11, and 7.1, with exploitation requiring the pds_fwctl module loaded and a compatible PDS network adapter present. No public exploit exists and EPSS is 0.17% (7th percentile), placing this as a low-priority stability fix unless deployments expose the fwctl device node to untrusted local users.
Deadlock in the Linux kernel's drm/msm (Qualcomm Snapdragon GPU) shrinker causes full kernel hang under memory reclaim pressure. The circular lock dependency arises when the kswapd0 thread holds fs_reclaim and the MSM gem shrinker calls dma_resv_lock(), which internally attempts to re-acquire fs_reclaim - producing a ABBA deadlock that renders the system unresponsive. Kernels in the affected range on Snapdragon-based hardware (Linux 6.17 through pre-patch 7.0.x and 6.18.x) are vulnerable; no public exploit code exists and no active exploitation has been confirmed.
NULL pointer dereference in the Linux kernel's batman-adv Bridge Loop Avoidance (BLA) subsystem crashes the kernel when a hard interface is concurrently decoupled from its mesh interface during ARP processing. Local users with low privileges on systems running batman-adv mesh networking can trigger a kernel panic, causing a full denial of service. No public exploit exists and EPSS stands at 0.21% (11th percentile), marking this as a low-urgency stability fix rather than an active threat.
Availability degradation in the Linux kernel's batman-adv throughput meter (tp_meter) subsystem arises from a reference counting race in the receiver shutdown path, where both `batadv_tp_receiver_shutdown()` and `batadv_tp_stop_all()` can simultaneously skip the `tp_vars` reference release when the shutdown timer expires before `timer_shutdown_sync()` is evaluated. The leaked reference accumulates with repeated triggering, progressively exhausting kernel memory resources and resulting in a local denial-of-service condition on systems running the batman-adv mesh networking module. With no public exploit identified at time of analysis and an EPSS score of 0.18% (8th percentile), this is a correctness-class fix with real impact only on systems explicitly running batman-adv.
Denial-of-service via the batman-adv Translation Table (TT) subsystem in the Linux kernel allows a local low-privileged attacker to trigger empty VLAN responses through the global TT state path, causing availability loss in the mesh networking stack. The flaw traces to an incomplete prior fix: commit 16116dac2339 patched the direct TT response path against inconsistent TT TLVLs, but left the indirect global TT response path unguarded, enabling the same class of inconsistency state. No public exploit has been identified and EPSS stands at 0.18% (8th percentile), reflecting low real-world exploitation probability.
Heap buffer overflow in the Linux kernel's hwmon adm1266 PMBus driver allows a local attacker or a malicious/buggy PMBus device to crash the kernel by inducing a record_count value exceeding 32 in a BLACKBOX_INFO response, overrunning the fixed 2048-byte dev_mem allocation in adm1266_nvmem_read_blackbox(). Systems with the adm1266 driver loaded against ADM1266 hardware are affected across multiple stable kernel branches; patched versions are confirmed across Linux 5.10.258 through 7.0.11. EPSS at 0.18% and absence of KEV listing indicate no active exploitation at time of analysis.
Kernel stack memory leaks to userspace through the adm1266 PMBus GPIO driver in the Linux kernel when the ADM1266 hardware returns a shorter-than-expected I2C block-read response. Both adm1266_gpio_get() and adm1266_gpio_get_multiple() assemble a 16-bit status word from two buffer bytes without first verifying that at least two bytes were returned; uninitialized stack data then propagates through the gpiolib subsystem into sysfs and char-device ioctls accessible to local users. No public exploit exists and EPSS probability is 0.18% (8th percentile), consistent with the hardware-specific, locally-exploitable nature of this flaw; patches have been released across all active stable kernel branches.
NULL pointer dereference in the Linux kernel netfilter x_tables subsystem allows a local attacker to crash the kernel via a race condition during network namespace teardown. The flaw exists because arp/ip(6)t_register_table() adds a table to the per-netns linked list before allocating its per-namespace hook ops structure, leaving a window where ops=NULL is visible to concurrent readers. If a network namespace exit runs concurrently during this window, nf_unregister_net_hooks() receives a NULL ops pointer and triggers a general protection fault. No public exploit has been identified at time of analysis, and EPSS is very low at 0.15%.
Bio memory leak in the Linux kernel NVMe driver causes kernel memory exhaustion under integrity-mapping failure conditions, affecting local low-privileged users on systems with NVMe integrity features enabled. The defect lies in the NVMe block-I/O path: a local `bio` pointer is always NULL, so when integrity mapping fails the associated bio object is never freed - the fix retrieves the bio directly from the request structure. With EPSS at 0.17% (7th percentile) and no CISA KEV listing, no public exploit has been identified at time of analysis, and real-world risk is confined to gradual memory exhaustion rather than immediate system compromise.
Preempt count leak in four hv-gpci sysfs show() callbacks in the Linux kernel powerpc subsystem causes progressive kernel stability degradation on IBM Power systems compiled with CONFIG_PREEMPT=y. Each successful read of the affected sysfs nodes leaves one preempt_disable() unmatched, incrementally raising preempt_count; once the count becomes non-zero on return to userspace, the next page fault is misidentified as occurring in an atomic context, generating SIGSEGV and triggering 'BUG: scheduling while atomic' during the resulting coredump. Patches are available across the 6.6, 7.0, and 7.1 stable kernel trees, with no public exploit identified at time of analysis.
Kernel panic (BUG) in the Linux netfs subsystem's netfs_write_begin() function causes local denial of service when a folio is unlocked without holding the lock, triggering the VM_BUG_ON_FOLIO(!folio_test_locked(folio)) assertion at mm/filemap.c:1504. The defect surfaces under concurrent write workloads on Ceph-backed filesystems using the netfs layer - the generic/013 xfstests case reproduces it with approximately 30% probability per run. A local, low-privileged user who can write to a Ceph mount can crash the kernel; no confidentiality or integrity impact is observed. No public exploit code exists and EPSS stands at 0.17% (6th percentile), consistent with a race-condition DoS confined to specific filesystem configurations.
Kernel crash via NULL pointer dereference in the Linux netfs layer is triggered by a local low-privileged user combining a streaming write, file truncation, and mmap read on the same netfs-backed file. Affected kernel versions span from 6.8 (commit 9ebff83e) through stable branches prior to 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and EPSS is 0.17%, indicating very low observed exploitation probability; however, a precise reproduction recipe is embedded in the upstream fix commit, substantially lowering the knowledge barrier for any attacker already holding local access.
Write-through mode deadlock in the Linux kernel netfs subsystem allows a local low-privileged user to hang the kernel, causing a denial of service. The defect in netfs_advance_writethrough() fails to unconditionally unlock a supplied folio, and prematurely marks it for writeback before the folio is fully written, creating a lock-ordering conflict against concurrent mmapped reads and writes. Patches are available across multiple stable kernel branches; no public exploit code or active exploitation has been identified.
Reference leak in the Linux kernel netfs subsystem exposes systems with network filesystem mounts to a local denial-of-service condition. The `netfs_write_begin()` function fails to drop its held reference on the netfs request object when `netfs_wait_for_read()` returns an error, violating reference-counting invariants in the kernel's network filesystem abstraction layer. A low-privileged local user who can trigger repeated write errors on a netfs-backed mount (NFS, Ceph, AFS, or similar) can slowly exhaust kernel memory resources. No public exploit code exists and EPSS is 0.17% (6th percentile), consistent with a low-priority kernel maintenance fix.
Reference leaks and memory corruption in the Linux kernel netfs subsystem allow a local unprivileged user to crash the system via crafted write operations on network-backed filesystems. The flaw in netfs_perform_write() incorrectly transitions folio->private between NULL, the NETFS_FOLIO_COPY_TO_CACHE sentinel, netfs_group pointers, and netfs_folio structs, enabling multiple private-data attachments, folio reference leaks, and netfs_group struct leaks that can exhaust kernel resources or trigger a kernel panic. No public exploit exists and EPSS sits at 0.17% (6th percentile), indicating no observed exploitation activity.
Null pointer dereference in the Linux kernel's block bio-integrity subsystem (`bio_integrity_map_user()`) allows a local low-privileged attacker to crash the kernel, causing a denial of service. The flaw stems from `pin_user_pages_fast()` being permitted to return a partial page-pin result that is never validated before `bvec_from_pages()` dereferences the uninitialized zero-address entry. Patches are available across multiple stable kernel branches and Ubuntu has issued USN-8593-1; no active exploitation has been identified (EPSS 0.17%, no CISA KEV listing).
NULL pointer dereference in the Linux kernel's drm/msm/adreno driver allows local low-privilege users to crash systems equipped with older Qualcomm Adreno GPU generations (a2xx through a4xx). Querying UBWC (Universal Bandwidth Compression) parameters from userspace on these GPU families - which have no UBWC support and therefore no initialized UBWC config structure - triggers a NULL dereference in adreno_get_param(), resulting in a kernel panic. No public exploit has been identified at time of analysis; EPSS is 0.17% (6th percentile), consistent with the hardware-specific, local-only scope.
In the Linux kernel, the following vulnerability has been resolved: ovpn: fix race between deleting interface and adding new peer While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration. It may happen during ovpn_dellink(), when all existing peers are freed and the device is queued for deregistration, but a CMD_PEER_NEW message comes in adding a new peer that takes again a reference to the netdev. At this point there is no way to release the device because we are under the assumption that all peers were already released. Fix the race condition by releasing all peers in ndo_uninit(), when the netdevice has already been removed from the netdev list. Also ovpn_peer_add() has now an extra check that forces the function to bail out if the device reg_state is not REGISTERED. This way any incoming CMD_PEER_NEW racing with the interface deletion routine will simply stop before adding the peer. Note that the above check happens while holding the netdev_lock to prevent racing netdev state changes. ovpn_dellink() is now empty and can be removed.
In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix error return when vfs_mkdir() fails When vfs_mkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdir_error to be reached with ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a proper error pointer. Fix this by extracting the error code from the error pointer when vfs_mkdir() fails.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Stop work before releasing hwmon device Sashiko reports: In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called. Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first. If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here. Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed.
In the Linux kernel, the following vulnerability has been resolved: tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow.
In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: remove the software node when deactivating the aggregator The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix exec_queue leak on width check in stream open In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix dma mapping leak on data setup error We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided. The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too.
In the Linux kernel, the following vulnerability has been resolved: Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size nexio_read_data() pulls data_len and x_len from a packed __be16 header in the device's interrupt packet and then walks packet->data[0..x_len) and packet->data[x_len..data_len) comparing each byte against a threshold. Both fields are 16-bit on the wire (max 65535). The existing adjustments shave at most 0x100 / 0x80 off, so the loop bound can still reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the packed header - so packet->data[] has 1017 valid bytes. read_data() callbacks are not given urb->actual_length, and nothing else bounds the walk. A device that lies about its length can get a ~64 KiB out-of-bounds read past the coherent DMA allocation. The first index whose byte exceeds NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the reported touch coordinates, so adjacent kernel memory contents leak to userspace as ABS_X / ABS_Y events. Far enough out, the read can also hit an unmapped page and fault. Fix this all by clamping data_len to the buffer's data[] capacity and x_len to data_len.
In the Linux kernel, the following vulnerability has been resolved: ACPI: button: Fix ACPI GPE handler leak during removal Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate.
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked When sfb has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (sfb in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(sfb) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (sfb). And herein lies the problem. - sfb will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full) [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216 [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0 [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3 [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000 [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000 [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000 [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0 [ 127.598390][ T453] PKRU: 55555554 [ 127.598509][ T453] Call Trace: [ 127.598629][ T453] <TASK> [ 127.598718][ T453] ? mark_held_locks+0x40/0x70 [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0 [ 127.599174][ T453] ? ktime_get+0x137/0x230 [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix setup list UAF on proc write error snd_pcm_oss_proc_write() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setup_list pointing at freed memory. A later OSS device open can then walk the stale list entry in snd_pcm_oss_look_for_setup() and dereference freed memory. Allocate the task name and initialize the setup entry before publishing the entry on setup_list. Also fetch the initial proc read iterator only after taking setup_mutex, so all setup_list traversal follows the same list lifetime rules.
In the Linux kernel, the following vulnerability has been resolved: ethtool: rss: fix indir_table and hkey leak on get_rxfh failure rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation.
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: call ethnl_ops_complete() on module flash errors When validate() fails we are skipping over ethnl_ops_complete() even tho we already called ethnl_ops_begin().
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: avoid leaking a netdev ref on module flash errors module_flash_fw_schedule() is missing undo for setting the "in_progress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt() The skb_clone() function can return NULL if memory allocation fails. send_mcast_pkt() calls skb_clone() without checking the return value, which can lead to a NULL pointer dereference in send_pkt() when it dereferences skb->data. Add a NULL check after skb_clone() and skip the peer if the clone fails.
In the Linux kernel, the following vulnerability has been resolved: bonding: refuse to enslave CAN devices syzbot reported a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The crash occurs because a virtual CAN device (vxcan) is being enslaved to a bonding master. During the enslavement process, the bonding driver mutates and modifies the network device states to fit an Ethernet-like aggregation model. However, CAN devices operate on a completely different Layer 2 architecture, relying on the CAN mid-layer private data structure (can_ml_priv) instead of standard Ethernet structures. Since bonding does not initialize or maintain these CAN structures, subsequent operations on the half-enslaved interface (such as closing associated sockets via isotp_release) lead to a null-pointer dereference when accessing the CAN receiver lists. Bonding CAN interfaces is architecturally invalid as CAN lacks MAC addresses, ARP capabilities, and standard Ethernet link-layer mechanisms. While generic loopback devices are blocked globally in net/core/dev.c, virtual CAN devices bypass this check because they do not carry the IFF_LOOPBACK flag, despite acting as local software-loopbacks. Fix this by explicitly blocking network devices of type ARPHRD_CAN from being enslaved at the very beginning of bond_enslave(). This prevents illegal state mutations, eliminates the resulting KASAN crashes, and avoids potential memory leaks from incomplete socket cleanups. As the CAN support has been added a long time after bonding the Fixes-tag points to the introduction of ARPHRD_CAN that would have needed a specific handling in bonding_main.c.
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in sysfs path Since the start of the git history, brport_store() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority). Nowadays, brport_store() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port: Only requires RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the two STP related attributes that require it. Remove the now stale comment from br_switchdev_set_port_flag(). The SWITCHDEV_F_DEFER flag can be removed in net-next. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 372, name: bash preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235) brport_store (net/bridge/br_sysfs_if.c:346) kernfs_fop_write_iter (fs/kernfs/file.c:352) new_sync_write (fs/read_write.c:595) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
In the Linux kernel, the following vulnerability has been resolved: ethtool: tsinfo: don't pass ERR_PTR to genlmsg_cancel on prepare failure The goto err label leads to: genlmsg_cancel(skb, ehdr); return ret; If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsg_cancel() would cause a crash.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix packet loop on netem when duplicate is on When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency.
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow tcf_mirred_act() checks sched_mirred_nest against MIRRED_NEST_LIMIT (4) to prevent deep recursion. However, when the action uses blockcast (tcfm_blockid != 0), the function returns at the tcf_blockcast() call BEFORE reaching the counter increment. As a result, the recursion counter never advances and the limit check is entirely bypassed. When two devices share a TC egress block with a mirred blockcast rule, a packet egressing on device A is mirrored to device B via blockcast; device B's egress TC re-enters tcf_mirred_act() via blockcast and mirrors back to A, creating an unbounded recursion loop: tcf_mirred_act -> tcf_blockcast -> tcf_mirred_to_dev -> dev_queue_xmit -> sch_handle_egress -> tcf_classify -> tcf_mirred_act -> (repeat) This recursion continues until the kernel stack overflows. The bug is reachable from an unprivileged user via unshare(CLONE_NEWUSER | CLONE_NEWNET): user namespaces grant CAP_NET_ADMIN in the new network namespace, which is sufficient to create dummy devices, attach clsact qdiscs with shared blocks, and install mirred blockcast filters. BUG: TASK stack guard page was hit at ffffc90000b7fff8 Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 2 UID: 1000 PID: 169 Comm: poc Not tainted 7.0.0-rc7-next-20260410 RIP: 0010:xas_find+0x17/0x480 Call Trace: xa_find+0x17b/0x1d0 tcf_mirred_act+0x640/0x1060 tcf_action_exec+0x400/0x530 basic_classify+0x128/0x1d0 tcf_classify+0xd83/0x1150 tc_run+0x328/0x620 __dev_queue_xmit+0x797/0x3100 tcf_mirred_to_dev+0x7b1/0xf70 tcf_mirred_act+0x68a/0x1060 [repeating ~30+ times until stack overflow] Kernel panic - not syncing: Fatal exception in interrupt Fix this by incrementing sched_mirred_nest before calling tcf_blockcast() and decrementing it on return, mirroring the non-blockcast path. This ensures subsequent recursive entries see the updated counter and are correctly limited by MIRRED_NEST_LIMIT.
In the Linux kernel, the following vulnerability has been resolved: net: mana: Add NULL guards in teardown path to prevent panic on attach failure When queue allocation fails partway through, the error cleanup frees and NULLs apc->tx_qp and apc->rxqs. Multiple teardown paths such as mana_remove(), mana_change_mtu() recovery, and internal error handling in mana_alloc_queues() can subsequently call into functions that dereference these pointers without NULL checks: - mana_chn_setxdp() dereferences apc->rxqs[0], causing a NULL pointer dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26). - mana_destroy_vport() iterates apc->rxqs without a NULL check. - mana_fence_rqs() iterates apc->rxqs without a NULL check. - mana_dealloc_queues() iterates apc->tx_qp without a NULL check. Add NULL guards for apc->rxqs in mana_fence_rqs(), mana_destroy_vport(), and before the mana_chn_setxdp() call. Add a NULL guard for apc->tx_qp in mana_dealloc_queues() to skip TX queue draining when TX queues were never allocated or already freed.
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in rt6_fill_node() Sashiko reported this issue [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings) without waiting for RCU readers; rt->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &rt->fib6_siblings, causing a CPU stall. fib6_del_route() always WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal. [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer The tagged FIFO path declares iio_buff on the stack with __aligned(8) but no initializer, but there is a hole in the structure, which will then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be copied, but the space between that and the timestamp are not initialized. Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") moved the untagged FIFO path to a kzalloc'd buffer in hw->scan, but for the tagged path it only added the alignment qualifier and not the initializer :( Fix this by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: iio: imu: adis16550: fix stack leak in trigger handler adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigger. Fix this all by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: iio: pressure: bmp280: fix stack leak in bmp580 trigger handler bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer lived in the private data, the move to a stack-local struct dropped the implicit zeroing. bme280_trigger_handler() was fixed up to handle this bug, but this driver was not fixed because there was no padding hole, but rather a short-fill issue. Fix this all by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: validate count before reading Status Update VDO A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer() wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++) regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i); which has two problems: USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed). The byte count latched in RXINFO is the number of bytes the port partner put on the wire, so a malicious partner that transmits a 31-byte frame can drive the loop one byte past the destination if the WCOVE BMC receiver does not enforce the PD object-count limit in hardware. The existing FIXME flagged this as unverified. Independently, regmap_read() takes an unsigned int * and stores a full unsigned int at the destination. Passing the byte pointer msg + i means each iteration writes four bytes; the high three are zero (val_bits is 8) and are normally overwritten by the next iteration, but the final iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration already writes three zero bytes past msg, which sits on the IRQ thread's stack in wcove_typec_irq(). Clamp the loop to sizeof(struct pd_message) and read each register into a local before storing only its low byte, so the copy can never exceed the destination regardless of what RXINFO reports.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_connector_change() The connector number in a UCSI CCI notification is a 7-bit field supplied by the PPM. ucsi_connector_change() uses it to index the ucsi->connector[] array without checking it against the number of connectors the PPM reported at init time, so a buggy or malicious PPM (EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 / glink transports) can drive schedule_work() on memory past the end of the array. Reject connector numbers that are zero or exceed cap.num_connectors before dereferencing the array.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: safe_serial: fix memory corruption with small endpoint Make sure that the bulk-out buffer size is at least eight bytes to avoid user-controlled slab corruption in "safe" mode should a malicious device report a smaller size.
Memory hotplug removal in the Linux kernel leaks device references because `find_memory_block()` acquires a kobject reference inside `remove_memory_blocks_and_altmaps()` that is never released, allowing the reference count to accumulate unchecked across repeated memory block removal cycles. Systems with memory hotplug support - including virtual machines using ACPI memory balloon drivers and bare-metal servers with hot-pluggable DIMM slots - are affected across multiple stable kernel branches, with patches confirmed for 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and exploitation probability is extremely low (EPSS 0.16%), though the availability impact is rated high: leaked references accumulated over repeated hotplug cycles can eventually precipitate a kernel panic.
Memory exhaustion in the Linux kernel WWAN IOSM driver allows a local low-privileged attacker to deplete kernel memory by repeatedly triggering error paths in `ipc_imem_init()` where memory allocated by `ipc_protocol_init()` is never released. Affected systems running kernel versions from 5.14 through the unpatched branches of 5.15, 6.1, 6.6, 6.12, 6.18, 7.0, and pre-7.1 with Intel WWAN IOSM modem hardware loaded are vulnerable to availability-impact memory exhaustion. No public exploit exists and EPSS probability sits at 0.16% (6th percentile), indicating negligible real-world exploitation likelihood; however, patched stable releases are available across all major kernel branches.
Kernel self-deadlock in the Linux phonet/pep subsystem allows a local low-privilege attacker to crash affected systems by triggering an inconsistent bottom-half (BH) lock state on a child PEP socket. The flaw exists from kernel 2.6.28 through unpatched stable branches up to 7.x, and is reachable only when the Phonet protocol module is active. No public exploit or active exploitation is confirmed; EPSS is 0.16% (6th percentile), consistent with the niche deployment context.
CPU exhaustion in the Linux kernel's cfg80211 WiFi subsystem allows an attacker within radio range to trigger a runaway loop in cfg80211_merge_profile() by broadcasting a specially crafted Multi-BSSID beacon frame, consuming up to 2 milliseconds of kernel CPU time per beacon received. Devices running Linux 5.2 and later with cfg80211-based WiFi drivers are affected across eight stable kernel branches, from 5.10.x through 7.0.x, until patched. No public exploit has been identified at time of analysis, and EPSS probability is 0.17% at the 7th percentile, indicating no observed active exploitation.
Invalid cleanup in the Linux kernel's tracing_map subsystem causes a kernel panic when memory allocation fails during element initialization. Specifically, the error path in tracing_map_elt_alloc() incorrectly invokes map->ops->elt_free() on uninitialized data when elt_alloc() was never successfully called, producing an invalid memory operation that crashes the kernel. This affects all kernel branches from 4.17 through the respective fixed stable releases. No public exploit exists and EPSS is 0.16% (6th percentile), but any local low-privileged user with access to the tracing subsystem who can induce allocation failures can trigger a denial of service.
Runtime PM reference count leak in the Linux kernel's Tegra I2C driver permanently prevents the affected I2C controller from entering runtime suspend when tegra_i2c_mutex_lock() returns an error. The asymmetric acquire-without-release of pm_runtime_get_sync() causes device power management to malfunction on NVIDIA Tegra SoC hardware, covering Linux 7.0 through pre-7.0.11 and pre-7.1. No public exploit exists and EPSS at 0.14% (4th percentile) reflects minimal exploitation interest; this is a stability and power management correctness defect rather than a security attack vector in the conventional sense.
NULL pointer dereference in the Linux kernel's SPI QUP (Qualcomm Universal Peripheral) driver causes a local denial-of-service condition affecting Qualcomm SoC-based Linux systems. When DMA setup fails during driver probe, the fallback to PIO mode leaves DMA channel pointers in a stale error state rather than clearing them to NULL; a subsequent probe failure or driver unbind then dereferences those error pointers, triggering a kernel panic. Patches are available across all active stable branches (5.10.259, 5.15.210, 6.1.176, 6.6.142, 6.12.92, 6.18.34, 7.0.11, 7.1); no public exploit has been identified and EPSS is at the 6th percentile, indicating negligible exploitation probability at this time.
Error pointer dereference in the Linux kernel ep93xx SPI driver causes kernel panic (denial of service) under specific driver lifecycle conditions on Cirrus Logic EP93xx ARM SoC hardware. When DMA channel setup fails during driver probe and falls back to PIO mode, the driver fails to clear the DMA channel pointers; any subsequent probe error or driver unbind then dereferences those stale error pointers, triggering a kernel oops or panic. No public exploit exists and EPSS of 0.16% (5th percentile) reflects negligible real-world exploitation probability - this is a targeted stability fix for a niche embedded platform.
Error pointer dereference in the Linux kernel's spi-sprd driver causes local denial of service on systems equipped with Spreadtrum (SPRD) SoC hardware. When DMA setup fails during driver probe and the driver falls back to PIO mode, a subsequent late probe error triggers a cleanup path that does not check the dma.enabled flag before attempting to release DMA channels - resulting in an error pointer dereference or double-channel-release and consequent kernel panic. No public exploit exists and EPSS sits at 0.17% (6th percentile), reflecting the highly hardware-specific nature of this flaw. Vendor-released patches are confirmed across multiple Linux stable branches.
Crash kernel panic in Linux kernel's KHO (Kexec Handover) subsystem causes kdump capture to fail due to a missing crash-kernel guard in kho_fill_kimage(). Systems configured with both KHO and a crash kernel (kdump) are affected: when a kernel crash transfers control to the crash kernel, KHO metadata pointing outside the reserved crash region triggers an invalid phys_to_virt() translation in kho_memory_init(), crashing the crash kernel itself and defeating the crash dump mechanism. No public exploit exists and EPSS at 0.16% (6th percentile) reflects appropriately low exploitation probability given the local-only, configuration-dependent nature of the flaw.
NULL pointer dereference in the Linux kernel's ARM Firmware Framework for Armv8-A (arm_ffa) bus driver allows a local actor with kernel module loading rights to crash the host system. The bus match callback unconditionally dereferences the id_table pointer of any registering FF-A client driver; a driver that omits id_table triggers an immediate kernel panic, producing a denial-of-service condition. EPSS at 0.17% (6th percentile) and absence from the CISA KEV catalog indicate no public exploit and negligible observed exploitation activity.
Early boot initialization on ARM Integrator/CP hardware in the Linux kernel triggers a NULL pointer dereference by invoking memory allocation routines before the memory management subsystem is operational, causing a kernel panic that renders affected systems unbootable. The regression was introduced by commit bdb249fce9ad4 and affects all Linux stable branches from that point through patched releases (5.10.258, 5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, 7.1). No public exploit exists, CISA KEV does not list this vulnerability, and EPSS sits at 0.17% (7th percentile), reflecting the narrowly scoped, hardware-specific nature of the defect.
Sleep-in-atomic-context denial of service in the Linux kernel btrfs filesystem driver allows a local low-privileged user to crash the system by triggering file sync operations while kernel tracing is active. The btrfs_sync_file trace event erroneously calls dput() - a function that may sleep - within an atomic context where sleeping is forbidden, producing a kernel BUG splat and potential panic. No active exploitation has been identified, EPSS is 0.16% (6th percentile), and the vulnerability requires a non-default kernel tracing configuration to be exploitable, substantially limiting real-world exposure.
Kernel panic in the Linux kernel's kprobes self-test module (test_kprobes) allows a local attacker or privileged user with debugfs write access to crash the kernel by triggering the KUnit kprobes test suite twice in succession. The root cause is that static kprobe and kretprobe variables retain stale address and flag data after unregister_kprobe, causing re-registration to fail with -EINVAL and subsequently triggering a kernel paging fault on the second test run. No public exploit is identified at time of analysis; EPSS at the 6th percentile and absence from CISA KEV confirm this as low-priority in production contexts.
Resource leak in the Texas Instruments ICSSG PRUETH Ethernet driver causes a device-tree node reference count to go unreleased on a specific probe error path, degrading kernel resource availability. Affected kernels from commit 511f6c1ae093c7045742299d29eba71925709a71 onward, prior to stable backports landing in 6.18.34, 7.0.11, and 7.1, are at risk only on hardware platforms carrying TI ICSSG silicon. EPSS sits at 0.17% (6th percentile) and no public exploit or CISA KEV entry exists, positioning this as a maintenance-tier stability fix rather than an active threat.
Incorrect zero_point calculation in the Linux kernel netfs layer's netfs_release_folio() function causes short reads and application-level I/O failures on network filesystem mounts when local pagecache size (i_size) exceeds the server-reported file size (remote_i_size). The bug affects local users on systems mounting CIFS or other netfs-backed shares with caching enabled, and was reproducible via a specific sequence of truncate, write, mapread, and copy_range operations on CIFS with the default cache option. No active exploitation is confirmed (not in CISA KEV), EPSS is 0.15% at the 5th percentile, and patches are confirmed available for kernel stable branches 7.0.11 and 7.1.
Incorrect dirty-region bookkeeping in the Linux kernel netfs subsystem (netfs_invalidate_folio) causes a local denial-of-service condition when streaming-write folios are partially invalidated. The bug is present in kernels from commit cce6bfa6ca0e through multiple stable branches and is fixed in 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit or active exploitation has been identified; EPSS sits at 0.17% (6th percentile), reflecting very low real-world exploitation probability despite the kernel's ubiquitous deployment.
Incorrect writeback state management in the Linux kernel's netfs and AFS subsystems allows a local low-privileged user on an AFS-mounted system to cause filesystem availability degradation. When netfs_write_single() or afs_single_writepages() skips a write due to lock contention under asynchronous writeback (WB_SYNC_NONE), the affected inode loses its dirty mark without the write being rescheduled, meaning data may never be flushed to the AFS server. No public exploit has been identified and the EPSS score of 0.17% at the 6th percentile reflects very low exploitation probability; patched versions are confirmed available across multiple stable kernel branches.
Memory leak in the Linux kernel's ath11k WiFi driver (Qualcomm Atheros 802.11ax) allows a local low-privileged user to exhaust kernel memory by triggering error paths in two WMI Wake-on-WLAN (WOW) command functions that fail to free associated socket buffers (skb) on failure. Patched across all active stable kernel branches (5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, and mainline 7.1). No active exploitation has been identified, with EPSS at 0.17% (7th percentile), consistent with a routine driver memory management fix rather than a weaponizable vulnerability.
Reference leak in the Linux kernel's Qualcomm Adreno a6xx GPU driver (drm/msm/adreno) can cause kernel memory reference exhaustion on affected hardware, leading to system instability or a kernel panic. The flaw in a6xx_gpu_init() allows of_parse_phandle() node references to escape release on multiple early error return paths, bypassing the required of_node_put() cleanup. No active exploitation has been identified; EPSS is 0.17% (6th percentile), no KEV listing exists, and impact is limited to availability on hardware-specific Linux deployments.
DMA mapping failures in the Linux kernel's dma-mapping subsystem crash device driver probes on ARM64 systems with SPARSEMEM due to an incorrect pfn_valid() precondition check in dma_map_resource(). On Raspberry Pi 4 and similar ARM64/SPARSEMEM platforms, MMIO registers whose physical addresses share a 128MB sparsemem section with RAM are misidentified as RAM, causing WARN_ON_ONCE to fire and dma_map_resource() to return DMA_MAPPING_ERROR, breaking peripheral initialization (e.g., spi_bcm2835 SPI controller). No public exploit identified at time of analysis; this is a functional kernel regression with local availability impact rather than a remotely exploitable security flaw.
The pds_core driver in the Linux kernel leaks debugfs dentry references on every firmware reset recovery due to missing dput() calls after debugfs_lookup(), and can crash the kernel when CONFIG_DEBUG_FS is disabled because ERR_PTR(-ENODEV) is not properly distinguished from NULL. A local user with standard privileges on a system hosting AMD/Pensando DPU hardware can trigger repeated firmware reset cycles to exhaust kernel memory, causing denial of service; on kernels with CONFIG_DEBUG_FS=n, a single reset recovery call can immediately crash the system via an invalid dput() on an error pointer. No public exploit exists and EPSS is 0.18% (7th percentile), but patches are available across multiple stable branches.
Resource exhaustion in the Linux kernel erofs filesystem driver allows a local low-privileged attacker to leak folio references via error paths in erofs_init_inode_xattrs(), potentially causing kernel memory resource exhaustion or denial of service. Affected systems are those running Linux kernel versions from 5.17 through the fix commits, where erofs filesystems with extended attributes (xattrs) are mounted. No public exploit code exists and the vulnerability is absent from CISA KEV; vendor-released patches are available in stable branches targeting 7.0.11 and 7.1.
Memory leak in the Linux kernel's btmtk (MediaTek Bluetooth USB) driver allows a local low-privileged user to exhaust kernel memory, causing denial of service. The vulnerability affects systems running Linux kernel from commit a1c49c434e15050b5dafe3b6f5cc732d4f02d657 onward, with patches confirmed in stable releases 6.6.142, 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and no active exploitation has been confirmed; an EPSS of 0.18% at the 7th percentile places this firmly in low-priority territory for most organizations.
Permanent battery hardware damage on Uniwell-based laptops can be triggered via the platform/x86/uniwill-laptop kernel driver by enabling the battery charging limit through the 'force' module parameter. Affected hardware is limited to older Uniwell OEM models manufactured around 2020 where the charging limit circuitry is incompatible with the feature and causes irreversible battery degradation. No public exploit exists and EPSS stands at 0.16% (6th percentile), reflecting the narrow hardware and configuration prerequisites; however, the impact is severe and permanent - affected batteries cannot be recovered once damaged.
Kernel memory exhaustion via ksmbd's POSIX-to-DACL ACL conversion causes a reliable denial-of-service against Linux SMB servers. Commit 299f962c0b02 introduced `check_add_overflow()` guards in `set_posix_acl_entries_dacl()` to prevent u16 DACL size wrap-around, but the resulting `break` statements bypass the `kfree(sid)` cleanup calls, leaking one or more `struct smb_sid` kernel heap allocations each time the overflow check fires. EPSS is 0.18% (8th percentile), no KEV listing exists, and no public exploit code has been identified, but the leak is deterministic and repeatable on every DACL request against a file with sufficient POSIX ACL entries, making memory exhaustion straightforward for any attacker with SMB access to the server.
Stack buffer overflow in the Linux kernel adm1266 PMBus hardware monitor driver allows a local low-privileged user to crash the kernel on systems equipped with an Analog Devices ADM1266 power sequencer chip. The vulnerable function allocates a 5-byte stack buffer but passes it to i2c_smbus_read_block_data(), which performs an unchecked memcpy of up to 32 bytes (I2C_SMBUS_BLOCK_MAX) before any length validation - overflowing the stack and causing a denial of service. No public exploit code exists and EPSS at 0.18% (7th percentile) confirms limited exploitation interest; patched versions are available across all active stable kernel branches.
Spurious kernel WARN() triggers in Linux kernel mm/memory.c during process teardown when NVIDIA UVM or HMM-capable GPU drivers are present alongside private file-backed mappings containing migrated anonymous folios. The unmap path incorrectly uses vma_is_anonymous() rather than folio_test_anon() to gate device-private/exclusive page handling, producing false-positive kernel warnings (not panics) during munmap or process exit in affected configurations. No public exploit has been identified at time of analysis; EPSS at 0.17% (7th percentile) reflects the narrow triggering conditions required and the non-weaponizable nature of a spurious WARN().
Stale ARM64 Memory Tagging Extension (MTE) tag exposure in the Linux kernel's huge zero folio allocation path undermines the init_on_free security guarantee on AArch64 systems. When the kernel is booted with init_on_free=1 and a 2MB anonymous mapping triggers the huge zero folio path (mapped as a PMD-special entry), the __GFP_ZEROTAGS flag causes post_alloc_hook() to skip tag memory clearing while content zeroing was already handled at free time - leaving whatever allocation tags were previously set accessible to user space. No public exploit has been identified at time of analysis, and EPSS stands at 0.17% (6th percentile), consistent with the narrow architectural and configuration prerequisites required to trigger the flaw.
Spinlock leak in the Linux kernel's huge page device migration subsystem causes a local denial of service via deadlock. A low-privileged local user who can trigger the `migrate_vma_insert_huge_pmd_page` code path while inducing `check_stable_address_space()` to fail will leave the PMD spinlock permanently held, deadlocking any subsequent thread that attempts to acquire it. No public exploit has been identified and EPSS at 0.17% (7th percentile) reflects negligible real-world exploitation probability; the vulnerability is not in CISA KEV.
Null pointer dereference in the Linux kernel's Bluetooth ISO reassembly path allows any Bluetooth broadcaster within radio range to crash a victim Linux host by transmitting an ISO_END PDU without a preceding ISO_START on a BIS (Broadcast Isochronous Stream) connection. Affected kernels span all stable branches from the ISO introduction commit (ccf74f2390d60a2f9a75ef496d2564abb478f46a) through fixed releases 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code or CISA KEV listing exists at time of analysis; EPSS is 0.18% (8th percentile), reflecting low current exploitation probability despite the unauthenticated wireless trigger available to BIS attackers.
Kernel stack address disclosure in the Linux kernel's Bluetooth L2CAP subsystem leaks 8 bytes of kernel virtual address space to a paired Bluetooth peer whenever a local user triggers an L2CAP Enhanced Credit-Based Reconfigure (ECRED) request. The flaw was introduced by commit 1c08108f3014 when DEFINE_RAW_FLEX() converted the on-stack PDU struct but left l2cap_send_cmd() receiving the local pointer's stack storage address and sizeof(pointer) instead of the struct address and struct size. As a result, the ECRED reconfigure feature has been functionally broken for local initiators since that commit, and every reconfigure attempt passively leaks a KASLR-randomized kernel stack address to the Bluetooth peer, potentially aiding ASLR/KASLR bypass. No public exploit is identified at time of analysis, and the EPSS score of 0.18% (7th percentile) reflects low automated exploitation probability.
NULL pointer dereference in the Linux kernel's ethtool PHY subsystem allows a local low-privileged user to crash the kernel and cause a denial of service. The flaw in `phy_prepare_data()` fails to check return values from `kstrdup()` for the strings `name`, `drvname`, `upstream_sfp_name`, and `downstream_sfp_name`; when allocation fails and returns NULL, `phy_reply_size()` subsequently calls `strlen()` unconditionally on the NULL pointer, triggering a kernel oops and system panic. No public exploit code has been identified and EPSS stands at 0.17% (6th percentile), but the availability impact is total - a kernel panic - making this a standard patching priority for any multi-user or shared Linux environment.
CPU pinning denial-of-service in the Linux kernel L2TP subsystem allows an unprivileged local user to wedge a host CPU indefinitely by exploiting an RCU list management mismatch in l2tp_session_unhash(). By creating a user network namespace (unshare -Urn) to obtain CAP_NET_ADMIN and then racing L2TP_CMD_SESSION_CREATE, L2TP_CMD_SESSION_DELETE, and L2TP_CMD_SESSION_GET against the same tunnel, an attacker causes a session list walker to enter an infinite loop with BH and preemption disabled - stalling RCU grace periods system-wide and rendering the thread unkillable via SIGKILL. No public exploit has been identified at time of analysis; EPSS at 0.17% (6th percentile) indicates low automated exploitation probability and no CISA KEV listing.
Memory leak in the Linux kernel igc driver's Frame Preemption (FPE) implementation affects systems with Intel I225/I226 Ethernet controllers running kernel versions from commit 5422570c0010bb968738f9256eb2bf83e79b4d63 onward. The function igc_fpe_xmit_smd_frame() allocates a socket buffer for SMD frame transmission but fails to release it when igc_fpe_init_tx_descriptor() returns an error, confirmed by kernel SLAB unreferenced-object traces showing 224-byte skb allocations going unfreed. No public exploit has been identified and EPSS stands at 0.17%, indicating negligible broad exploitation interest; the practical exposure is limited to TSN-capable deployments with FPE explicitly enabled.
NULL pointer dereference in the Linux kernel's PCM512x ASoC audio codec driver crashes the kernel when a local low-privileged user writes to the overclocking mixer kcontrol. The driver's pcm512x_overclock_xxx_put() handler incorrectly invokes snd_soc_dapm_kcontrol_to_dapm() on a standard mixer kcontrol - an accessor only valid for DAPM kcontrols - returning NULL and triggering a kernel panic. No public exploit has been identified and EPSS stands at 0.16% (6th percentile), reflecting low exploitation likelihood; impact is confined to denial of service on systems with PCM512x audio hardware.
KVM arm64 vGIC in the Linux kernel leaks kernel memory when vCPU initialization fails, enabling a local attacker with VM-creation privileges to exhaust host memory and cause denial of service. The defect is a missing cleanup call in the kvm_vgic_vcpu_init() error path: private IRQs allocated prior to a redistributor iodev registration failure are never freed before the failed vCPU structure is released. No public exploit has been identified at time of analysis; an EPSS score of 0.17% (6th percentile) reflects low opportunistic exploitation probability, and the flaw is not listed in CISA KEV.
Out-of-bounds heap read in the Linux kernel's fwctl pds driver allows a local low-privileged user to crash the kernel by submitting an undersized RPC buffer, resulting in a denial of service. Affected kernel versions include Linux 6.15 and all stable trees prior to 6.18.34, 7.0.11, and 7.1, with exploitation requiring the pds_fwctl module loaded and a compatible PDS network adapter present. No public exploit exists and EPSS is 0.17% (7th percentile), placing this as a low-priority stability fix unless deployments expose the fwctl device node to untrusted local users.
Deadlock in the Linux kernel's drm/msm (Qualcomm Snapdragon GPU) shrinker causes full kernel hang under memory reclaim pressure. The circular lock dependency arises when the kswapd0 thread holds fs_reclaim and the MSM gem shrinker calls dma_resv_lock(), which internally attempts to re-acquire fs_reclaim - producing a ABBA deadlock that renders the system unresponsive. Kernels in the affected range on Snapdragon-based hardware (Linux 6.17 through pre-patch 7.0.x and 6.18.x) are vulnerable; no public exploit code exists and no active exploitation has been confirmed.
NULL pointer dereference in the Linux kernel's batman-adv Bridge Loop Avoidance (BLA) subsystem crashes the kernel when a hard interface is concurrently decoupled from its mesh interface during ARP processing. Local users with low privileges on systems running batman-adv mesh networking can trigger a kernel panic, causing a full denial of service. No public exploit exists and EPSS stands at 0.21% (11th percentile), marking this as a low-urgency stability fix rather than an active threat.
Availability degradation in the Linux kernel's batman-adv throughput meter (tp_meter) subsystem arises from a reference counting race in the receiver shutdown path, where both `batadv_tp_receiver_shutdown()` and `batadv_tp_stop_all()` can simultaneously skip the `tp_vars` reference release when the shutdown timer expires before `timer_shutdown_sync()` is evaluated. The leaked reference accumulates with repeated triggering, progressively exhausting kernel memory resources and resulting in a local denial-of-service condition on systems running the batman-adv mesh networking module. With no public exploit identified at time of analysis and an EPSS score of 0.18% (8th percentile), this is a correctness-class fix with real impact only on systems explicitly running batman-adv.
Denial-of-service via the batman-adv Translation Table (TT) subsystem in the Linux kernel allows a local low-privileged attacker to trigger empty VLAN responses through the global TT state path, causing availability loss in the mesh networking stack. The flaw traces to an incomplete prior fix: commit 16116dac2339 patched the direct TT response path against inconsistent TT TLVLs, but left the indirect global TT response path unguarded, enabling the same class of inconsistency state. No public exploit has been identified and EPSS stands at 0.18% (8th percentile), reflecting low real-world exploitation probability.
Heap buffer overflow in the Linux kernel's hwmon adm1266 PMBus driver allows a local attacker or a malicious/buggy PMBus device to crash the kernel by inducing a record_count value exceeding 32 in a BLACKBOX_INFO response, overrunning the fixed 2048-byte dev_mem allocation in adm1266_nvmem_read_blackbox(). Systems with the adm1266 driver loaded against ADM1266 hardware are affected across multiple stable kernel branches; patched versions are confirmed across Linux 5.10.258 through 7.0.11. EPSS at 0.18% and absence of KEV listing indicate no active exploitation at time of analysis.
Kernel stack memory leaks to userspace through the adm1266 PMBus GPIO driver in the Linux kernel when the ADM1266 hardware returns a shorter-than-expected I2C block-read response. Both adm1266_gpio_get() and adm1266_gpio_get_multiple() assemble a 16-bit status word from two buffer bytes without first verifying that at least two bytes were returned; uninitialized stack data then propagates through the gpiolib subsystem into sysfs and char-device ioctls accessible to local users. No public exploit exists and EPSS probability is 0.18% (8th percentile), consistent with the hardware-specific, locally-exploitable nature of this flaw; patches have been released across all active stable kernel branches.
NULL pointer dereference in the Linux kernel netfilter x_tables subsystem allows a local attacker to crash the kernel via a race condition during network namespace teardown. The flaw exists because arp/ip(6)t_register_table() adds a table to the per-netns linked list before allocating its per-namespace hook ops structure, leaving a window where ops=NULL is visible to concurrent readers. If a network namespace exit runs concurrently during this window, nf_unregister_net_hooks() receives a NULL ops pointer and triggers a general protection fault. No public exploit has been identified at time of analysis, and EPSS is very low at 0.15%.
Bio memory leak in the Linux kernel NVMe driver causes kernel memory exhaustion under integrity-mapping failure conditions, affecting local low-privileged users on systems with NVMe integrity features enabled. The defect lies in the NVMe block-I/O path: a local `bio` pointer is always NULL, so when integrity mapping fails the associated bio object is never freed - the fix retrieves the bio directly from the request structure. With EPSS at 0.17% (7th percentile) and no CISA KEV listing, no public exploit has been identified at time of analysis, and real-world risk is confined to gradual memory exhaustion rather than immediate system compromise.
Preempt count leak in four hv-gpci sysfs show() callbacks in the Linux kernel powerpc subsystem causes progressive kernel stability degradation on IBM Power systems compiled with CONFIG_PREEMPT=y. Each successful read of the affected sysfs nodes leaves one preempt_disable() unmatched, incrementally raising preempt_count; once the count becomes non-zero on return to userspace, the next page fault is misidentified as occurring in an atomic context, generating SIGSEGV and triggering 'BUG: scheduling while atomic' during the resulting coredump. Patches are available across the 6.6, 7.0, and 7.1 stable kernel trees, with no public exploit identified at time of analysis.
Kernel panic (BUG) in the Linux netfs subsystem's netfs_write_begin() function causes local denial of service when a folio is unlocked without holding the lock, triggering the VM_BUG_ON_FOLIO(!folio_test_locked(folio)) assertion at mm/filemap.c:1504. The defect surfaces under concurrent write workloads on Ceph-backed filesystems using the netfs layer - the generic/013 xfstests case reproduces it with approximately 30% probability per run. A local, low-privileged user who can write to a Ceph mount can crash the kernel; no confidentiality or integrity impact is observed. No public exploit code exists and EPSS stands at 0.17% (6th percentile), consistent with a race-condition DoS confined to specific filesystem configurations.
Kernel crash via NULL pointer dereference in the Linux netfs layer is triggered by a local low-privileged user combining a streaming write, file truncation, and mmap read on the same netfs-backed file. Affected kernel versions span from 6.8 (commit 9ebff83e) through stable branches prior to 6.12.92, 6.18.34, 7.0.11, and 7.1. No public exploit code exists and EPSS is 0.17%, indicating very low observed exploitation probability; however, a precise reproduction recipe is embedded in the upstream fix commit, substantially lowering the knowledge barrier for any attacker already holding local access.
Write-through mode deadlock in the Linux kernel netfs subsystem allows a local low-privileged user to hang the kernel, causing a denial of service. The defect in netfs_advance_writethrough() fails to unconditionally unlock a supplied folio, and prematurely marks it for writeback before the folio is fully written, creating a lock-ordering conflict against concurrent mmapped reads and writes. Patches are available across multiple stable kernel branches; no public exploit code or active exploitation has been identified.
Reference leak in the Linux kernel netfs subsystem exposes systems with network filesystem mounts to a local denial-of-service condition. The `netfs_write_begin()` function fails to drop its held reference on the netfs request object when `netfs_wait_for_read()` returns an error, violating reference-counting invariants in the kernel's network filesystem abstraction layer. A low-privileged local user who can trigger repeated write errors on a netfs-backed mount (NFS, Ceph, AFS, or similar) can slowly exhaust kernel memory resources. No public exploit code exists and EPSS is 0.17% (6th percentile), consistent with a low-priority kernel maintenance fix.
Reference leaks and memory corruption in the Linux kernel netfs subsystem allow a local unprivileged user to crash the system via crafted write operations on network-backed filesystems. The flaw in netfs_perform_write() incorrectly transitions folio->private between NULL, the NETFS_FOLIO_COPY_TO_CACHE sentinel, netfs_group pointers, and netfs_folio structs, enabling multiple private-data attachments, folio reference leaks, and netfs_group struct leaks that can exhaust kernel resources or trigger a kernel panic. No public exploit exists and EPSS sits at 0.17% (6th percentile), indicating no observed exploitation activity.
Null pointer dereference in the Linux kernel's block bio-integrity subsystem (`bio_integrity_map_user()`) allows a local low-privileged attacker to crash the kernel, causing a denial of service. The flaw stems from `pin_user_pages_fast()` being permitted to return a partial page-pin result that is never validated before `bvec_from_pages()` dereferences the uninitialized zero-address entry. Patches are available across multiple stable kernel branches and Ubuntu has issued USN-8593-1; no active exploitation has been identified (EPSS 0.17%, no CISA KEV listing).
NULL pointer dereference in the Linux kernel's drm/msm/adreno driver allows local low-privilege users to crash systems equipped with older Qualcomm Adreno GPU generations (a2xx through a4xx). Querying UBWC (Universal Bandwidth Compression) parameters from userspace on these GPU families - which have no UBWC support and therefore no initialized UBWC config structure - triggers a NULL dereference in adreno_get_param(), resulting in a kernel panic. No public exploit has been identified at time of analysis; EPSS is 0.17% (6th percentile), consistent with the hardware-specific, local-only scope.
In the Linux kernel, the following vulnerability has been resolved: ovpn: fix race between deleting interface and adding new peer While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration. It may happen during ovpn_dellink(), when all existing peers are freed and the device is queued for deregistration, but a CMD_PEER_NEW message comes in adding a new peer that takes again a reference to the netdev. At this point there is no way to release the device because we are under the assumption that all peers were already released. Fix the race condition by releasing all peers in ndo_uninit(), when the netdevice has already been removed from the netdev list. Also ovpn_peer_add() has now an extra check that forces the function to bail out if the device reg_state is not REGISTERED. This way any incoming CMD_PEER_NEW racing with the interface deletion routine will simply stop before adding the peer. Note that the above check happens while holding the netdev_lock to prevent racing netdev state changes. ovpn_dellink() is now empty and can be removed.
In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix error return when vfs_mkdir() fails When vfs_mkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdir_error to be reached with ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a proper error pointer. Fix this by extracting the error code from the error pointer when vfs_mkdir() fails.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Stop work before releasing hwmon device Sashiko reports: In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called. Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first. If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here. Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed.
In the Linux kernel, the following vulnerability has been resolved: tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow.
In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: remove the software node when deactivating the aggregator The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix exec_queue leak on width check in stream open In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix dma mapping leak on data setup error We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided. The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too.
In the Linux kernel, the following vulnerability has been resolved: Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size nexio_read_data() pulls data_len and x_len from a packed __be16 header in the device's interrupt packet and then walks packet->data[0..x_len) and packet->data[x_len..data_len) comparing each byte against a threshold. Both fields are 16-bit on the wire (max 65535). The existing adjustments shave at most 0x100 / 0x80 off, so the loop bound can still reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the packed header - so packet->data[] has 1017 valid bytes. read_data() callbacks are not given urb->actual_length, and nothing else bounds the walk. A device that lies about its length can get a ~64 KiB out-of-bounds read past the coherent DMA allocation. The first index whose byte exceeds NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the reported touch coordinates, so adjacent kernel memory contents leak to userspace as ABS_X / ABS_Y events. Far enough out, the read can also hit an unmapped page and fault. Fix this all by clamping data_len to the buffer's data[] capacity and x_len to data_len.
In the Linux kernel, the following vulnerability has been resolved: ACPI: button: Fix ACPI GPE handler leak during removal Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate.
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked When sfb has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (sfb in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(sfb) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (sfb). And herein lies the problem. - sfb will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full) [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216 [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0 [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3 [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000 [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000 [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000 [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0 [ 127.598390][ T453] PKRU: 55555554 [ 127.598509][ T453] Call Trace: [ 127.598629][ T453] <TASK> [ 127.598718][ T453] ? mark_held_locks+0x40/0x70 [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0 [ 127.599174][ T453] ? ktime_get+0x137/0x230 [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix setup list UAF on proc write error snd_pcm_oss_proc_write() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setup_list pointing at freed memory. A later OSS device open can then walk the stale list entry in snd_pcm_oss_look_for_setup() and dereference freed memory. Allocate the task name and initialize the setup entry before publishing the entry on setup_list. Also fetch the initial proc read iterator only after taking setup_mutex, so all setup_list traversal follows the same list lifetime rules.
In the Linux kernel, the following vulnerability has been resolved: ethtool: rss: fix indir_table and hkey leak on get_rxfh failure rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation.
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: call ethnl_ops_complete() on module flash errors When validate() fails we are skipping over ethnl_ops_complete() even tho we already called ethnl_ops_begin().
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: avoid leaking a netdev ref on module flash errors module_flash_fw_schedule() is missing undo for setting the "in_progress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt() The skb_clone() function can return NULL if memory allocation fails. send_mcast_pkt() calls skb_clone() without checking the return value, which can lead to a NULL pointer dereference in send_pkt() when it dereferences skb->data. Add a NULL check after skb_clone() and skip the peer if the clone fails.
In the Linux kernel, the following vulnerability has been resolved: bonding: refuse to enslave CAN devices syzbot reported a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The crash occurs because a virtual CAN device (vxcan) is being enslaved to a bonding master. During the enslavement process, the bonding driver mutates and modifies the network device states to fit an Ethernet-like aggregation model. However, CAN devices operate on a completely different Layer 2 architecture, relying on the CAN mid-layer private data structure (can_ml_priv) instead of standard Ethernet structures. Since bonding does not initialize or maintain these CAN structures, subsequent operations on the half-enslaved interface (such as closing associated sockets via isotp_release) lead to a null-pointer dereference when accessing the CAN receiver lists. Bonding CAN interfaces is architecturally invalid as CAN lacks MAC addresses, ARP capabilities, and standard Ethernet link-layer mechanisms. While generic loopback devices are blocked globally in net/core/dev.c, virtual CAN devices bypass this check because they do not carry the IFF_LOOPBACK flag, despite acting as local software-loopbacks. Fix this by explicitly blocking network devices of type ARPHRD_CAN from being enslaved at the very beginning of bond_enslave(). This prevents illegal state mutations, eliminates the resulting KASAN crashes, and avoids potential memory leaks from incomplete socket cleanups. As the CAN support has been added a long time after bonding the Fixes-tag points to the introduction of ARPHRD_CAN that would have needed a specific handling in bonding_main.c.
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in sysfs path Since the start of the git history, brport_store() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority). Nowadays, brport_store() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port: Only requires RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the two STP related attributes that require it. Remove the now stale comment from br_switchdev_set_port_flag(). The SWITCHDEV_F_DEFER flag can be removed in net-next. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 372, name: bash preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235) brport_store (net/bridge/br_sysfs_if.c:346) kernfs_fop_write_iter (fs/kernfs/file.c:352) new_sync_write (fs/read_write.c:595) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
In the Linux kernel, the following vulnerability has been resolved: ethtool: tsinfo: don't pass ERR_PTR to genlmsg_cancel on prepare failure The goto err label leads to: genlmsg_cancel(skb, ehdr); return ret; If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsg_cancel() would cause a crash.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix packet loop on netem when duplicate is on When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency.
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow tcf_mirred_act() checks sched_mirred_nest against MIRRED_NEST_LIMIT (4) to prevent deep recursion. However, when the action uses blockcast (tcfm_blockid != 0), the function returns at the tcf_blockcast() call BEFORE reaching the counter increment. As a result, the recursion counter never advances and the limit check is entirely bypassed. When two devices share a TC egress block with a mirred blockcast rule, a packet egressing on device A is mirrored to device B via blockcast; device B's egress TC re-enters tcf_mirred_act() via blockcast and mirrors back to A, creating an unbounded recursion loop: tcf_mirred_act -> tcf_blockcast -> tcf_mirred_to_dev -> dev_queue_xmit -> sch_handle_egress -> tcf_classify -> tcf_mirred_act -> (repeat) This recursion continues until the kernel stack overflows. The bug is reachable from an unprivileged user via unshare(CLONE_NEWUSER | CLONE_NEWNET): user namespaces grant CAP_NET_ADMIN in the new network namespace, which is sufficient to create dummy devices, attach clsact qdiscs with shared blocks, and install mirred blockcast filters. BUG: TASK stack guard page was hit at ffffc90000b7fff8 Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 2 UID: 1000 PID: 169 Comm: poc Not tainted 7.0.0-rc7-next-20260410 RIP: 0010:xas_find+0x17/0x480 Call Trace: xa_find+0x17b/0x1d0 tcf_mirred_act+0x640/0x1060 tcf_action_exec+0x400/0x530 basic_classify+0x128/0x1d0 tcf_classify+0xd83/0x1150 tc_run+0x328/0x620 __dev_queue_xmit+0x797/0x3100 tcf_mirred_to_dev+0x7b1/0xf70 tcf_mirred_act+0x68a/0x1060 [repeating ~30+ times until stack overflow] Kernel panic - not syncing: Fatal exception in interrupt Fix this by incrementing sched_mirred_nest before calling tcf_blockcast() and decrementing it on return, mirroring the non-blockcast path. This ensures subsequent recursive entries see the updated counter and are correctly limited by MIRRED_NEST_LIMIT.
In the Linux kernel, the following vulnerability has been resolved: net: mana: Add NULL guards in teardown path to prevent panic on attach failure When queue allocation fails partway through, the error cleanup frees and NULLs apc->tx_qp and apc->rxqs. Multiple teardown paths such as mana_remove(), mana_change_mtu() recovery, and internal error handling in mana_alloc_queues() can subsequently call into functions that dereference these pointers without NULL checks: - mana_chn_setxdp() dereferences apc->rxqs[0], causing a NULL pointer dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26). - mana_destroy_vport() iterates apc->rxqs without a NULL check. - mana_fence_rqs() iterates apc->rxqs without a NULL check. - mana_dealloc_queues() iterates apc->tx_qp without a NULL check. Add NULL guards for apc->rxqs in mana_fence_rqs(), mana_destroy_vport(), and before the mana_chn_setxdp() call. Add a NULL guard for apc->tx_qp in mana_dealloc_queues() to skip TX queue draining when TX queues were never allocated or already freed.
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in rt6_fill_node() Sashiko reported this issue [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings) without waiting for RCU readers; rt->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &rt->fib6_siblings, causing a CPU stall. fib6_del_route() always WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal. [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer The tagged FIFO path declares iio_buff on the stack with __aligned(8) but no initializer, but there is a hole in the structure, which will then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be copied, but the space between that and the timestamp are not initialized. Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") moved the untagged FIFO path to a kzalloc'd buffer in hw->scan, but for the tagged path it only added the alignment qualifier and not the initializer :( Fix this by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: iio: imu: adis16550: fix stack leak in trigger handler adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigger. Fix this all by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: iio: pressure: bmp280: fix stack leak in bmp580 trigger handler bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer lived in the private data, the move to a stack-local struct dropped the implicit zeroing. bme280_trigger_handler() was fixed up to handle this bug, but this driver was not fixed because there was no padding hole, but rather a short-fill issue. Fix this all by just zero-initializing the structure on the stack.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: validate count before reading Status Update VDO A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer() wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++) regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i); which has two problems: USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed). The byte count latched in RXINFO is the number of bytes the port partner put on the wire, so a malicious partner that transmits a 31-byte frame can drive the loop one byte past the destination if the WCOVE BMC receiver does not enforce the PD object-count limit in hardware. The existing FIXME flagged this as unverified. Independently, regmap_read() takes an unsigned int * and stores a full unsigned int at the destination. Passing the byte pointer msg + i means each iteration writes four bytes; the high three are zero (val_bits is 8) and are normally overwritten by the next iteration, but the final iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration already writes three zero bytes past msg, which sits on the IRQ thread's stack in wcove_typec_irq(). Clamp the loop to sizeof(struct pd_message) and read each register into a local before storing only its low byte, so the copy can never exceed the destination regardless of what RXINFO reports.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_connector_change() The connector number in a UCSI CCI notification is a 7-bit field supplied by the PPM. ucsi_connector_change() uses it to index the ucsi->connector[] array without checking it against the number of connectors the PPM reported at init time, so a buggy or malicious PPM (EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 / glink transports) can drive schedule_work() on memory past the end of the array. Reject connector numbers that are zero or exceed cap.num_connectors before dereferencing the array.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: safe_serial: fix memory corruption with small endpoint Make sure that the bulk-out buffer size is at least eight bytes to avoid user-controlled slab corruption in "safe" mode should a malicious device report a smaller size.