Linux
Monthly
In the Linux kernel, the following vulnerability has been resolved: net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header). However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skb_gro_receive(), leading to several issues: 1. skb_gro_receive() checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) includes mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check with p->mac_header < 8 bytes. When ipv6_gro_complete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->mac_header. 2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q / ETH_P_8021AD) to aggregate beyond 64KB because p->protocol != ETH_P_IPV6 was true. 3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB. Fix skb_gro_receive() to strictly enforce: - NAPI_GRO_CB(skb)->proto == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) - Protocol must be either ETH_P_IP or ETH_P_IPV6 - If ETH_P_IPV6, p->mac_header must be at least sizeof(struct hop_jumbo_hdr) Returning -E2BIG from skb_gro_receive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping. This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y.
Boot registry parameter injection in IGEL OS 12 (before 12.7.6) and IGEL OS 11 (before 11.11.150) allows an attacker with physical access to execute arbitrary Linux kernel command-line parameters by writing to an unencrypted, unsigned configuration partition that the signed bootloader reads at startup. The attack is particularly dangerous because it does not alter the measured boot code path, meaning TPM PCR attestation does not detect the tampering - effectively defeating the trust assumptions of the secure boot and full-disk encryption stack. A publicly available exploit script and a DEF CON 34 presentation detail the technique; no CISA KEV listing has been issued at time of analysis, indicating exploitation has not been confirmed at scale.
vmclock in the Linux kernel exposes a shared ABI memory page that a low-privileged guest process can upgrade from read-only to writable using mprotect(), allowing direct corruption of host-maintained timekeeping fields including sequence counters, UTC time, and TSC offsets. Affected deployments are virtualized Linux guests running kernels prior to patched stable releases 6.18.47, 7.2.1, and 7.1.11, where the vmclock miscdevice driver fails to clear VM_MAYWRITE on read-only mmap paths. No public exploit code has been identified at time of analysis, and EPSS at 0.15% (5th percentile) reflects low observed exploitation pressure despite a CVSS 8.8 score driven by the scope-changing guest-to-host integrity impact.
Out-of-bounds memory write in the Linux kernel's device tree reserved memory subsystem allows an attacker with control over device tree content to corrupt kernel memory at boot time, with theoretical full kernel compromise (C:H/I:H/A:H). The fdt_scan_reserved_mem() function writes past the end of a fixed-size local array when a device tree blob defines more dynamically-placed /reserved-memory subnodes than MAX_RESERVED_REGIONS allows. Despite a CVSS score of 8.4, exploitation is heavily constrained by the requirement to modify device tree content before boot - a capability requiring privileged firmware access - and EPSS at 0.16% (5th percentile) reflects negligible observed exploitation probability. No public exploit has been identified and the vulnerability is absent from CISA KEV.
Insufficient validation of S1G (802.11ah/Wi-Fi HaLow) Target Wake Time setup frames in the Linux kernel's mac80211 subsystem allows an unauthenticated adjacent-network attacker to submit a malformed individual TWT agreement whose parameter block is shorter than the full struct ieee80211_twt_params. The driver callback drv_add_twt_setup() and associated kernel tracepoint both consume the complete parameters structure regardless of the truncated length, potentially triggering kernel memory corruption, out-of-bounds reads exposing sensitive kernel memory, or a denial-of-service crash. No public exploit code has been identified, CISA KEV listing is absent, and patches are confirmed across seven stable kernel branches; real-world exposure is substantially narrowed by the requirement for S1G hardware.
Dangling pointer dereference in the Linux kernel Bluetooth ISO subsystem exposes systems running kernel versions prior to 6.18.44, 7.1.8, and 7.2 to potential kernel memory corruption from adjacent Bluetooth attackers. After iso_conn_del() is invoked, ISO sockets may continue to dereference the freed hcon (HCI connection) pointer due to imprecise reference-counting logic, creating a use-after-free-class condition in kernel space. Despite a high NVD CVSS score of 8.8, the EPSS rating of 0.15% (5th percentile) and absence from CISA KEV indicate no public exploit or observed active exploitation at time of analysis.
Deadlock in the Linux kernel's iomap subsystem allows local attackers to cause a denial of service by exhausting the shared bioset used by both iomap_split_ioend and its input bios. The circular dependency in bioset allocation halts I/O completion on iomap-backed filesystems (XFS, ext4 direct I/O) and can hang the affected system. No active exploitation has been confirmed (not in CISA KEV) and the EPSS probability is very low at 0.15% (5th percentile), but the impact on availability is total for the affected I/O path.
In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
Bitmap overflow and incorrect global accounting in the Linux kernel's percpu-km memory allocator (`mm/percpu-km`) allow a local low-privileged attacker on SMP/NUMA systems to corrupt kernel memory, with potential for privilege escalation or kernel crash. Two separate commits introduced the flaws: a63d4ac4ab609 caused `pcpu_create_chunk()` to write beyond the `chunk->populated` bitmap when `nr_units > 1`, and b539b87fed37f introduced the companion `pcpu_nr_empty_pop_pages` accounting error. Fixes have been backported to eight stable kernel branches (5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8, 7.2); no public exploit has been identified at time of analysis.
Out-of-bounds read in the Linux kernel SCTP subsystem leaks up to four bytes of receive-buffer tail memory to remote unauthenticated attackers via a malformed INIT chunk. When an Adaptation Layer Indication parameter is sent with only its 4-byte header (omitting the mandatory 32-bit Adaptation Code Point), the kernel reads past the declared parameter boundary and copies those bytes into the state cookie of the INIT ACK response, exposing them to the peer. No public exploit has been identified and EPSS of 0.16% (6th percentile) indicates low exploitation probability, though the unauthenticated, network-accessible attack surface on any SCTP-enabled system warrants prompt patching.
Use-after-free in the Linux kernel ALSA PCM subsystem allows a local low-privilege attacker to corrupt kernel memory by exploiting a race between snd_pcm_drain() and snd_pcm_unlink() on linked streams. When a drain wait terminates by signal or timeout while group membership is concurrently modified by an unlink, a stack-allocated wait queue entry is left queued on a freed peer stream's sleep list; a subsequent wake_up() call then dereferences that freed stack frame. No public exploit code or CISA KEV listing exists at time of analysis; the EPSS of 0.16% (6th percentile) reflects low near-term exploitation probability.
In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
Use-after-free in the Linux kernel's IPVS (IP Virtual Server) connection-synchronization path allows corruption of the connection hash table on backup directors running the IPVS sync daemon. When a synced connection is bound to a destination that carries the IP_VS_CONN_F_ONE_PACKET flag, expiry logic wrongly skips unlinking the conn_tab node, leaving a stale hash entry pointing at a freed struct ip_vs_conn. There is no public exploit identified at time of analysis and EPSS is very low (0.16%), so despite the auto-assigned 9.8 rating this is a memory-safety defect in a specialized load-balancing feature rather than a broadly weaponizable RCE.
Restriction bypass in the Linux kernel's io_uring subsystem allows a local low-privileged user to shed per-task io_uring security restrictions by executing exec(). When a task that has established io_uring restrictions calls exec(), the kernel's exec cancellation path invokes __io_uring_free(), which incorrectly frees both the task context and the per-task restriction simultaneously. Any io_uring ring created by the post-exec process is then entirely unrestricted, defeating sandbox and policy enforcement intended to constrain io_uring operations. No public exploit has been identified at time of analysis, but the CVSS score of 8.4 with Changed Scope (S:C) reflects that the bypass can expose confidentiality and integrity of resources guarded by the dropped restrictions.
The spi-qpic-snand NAND flash driver in Linux kernel 6.18 and later contains a command-ordering defect that causes every SET_FEATURE write to apply the previous operation's value rather than the intended one, producing an off-by-one effect. On Qualcomm IPQ5018-based hardware (confirmed on TP-Link Archer AX55 v1 with ESMT F50L1G41LB flash), this defect became destructive in v6.18 when SPI-NAND OTP support was introduced: the 'disable OTP mode' call erroneously leaves CFG_OTP_ENABLE set permanently, causing all subsequent flash reads to return OTP area content and all writes to fail with -EIO, rendering the device unbootable. No public exploit identified at time of analysis; EPSS of 0.15% (5th percentile) correctly reflects that this is a driver logic defect rather than a traditionally attacker-controllable vulnerability.
In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
Integer truncation in the Linux kernel s390/dasd ECKD driver exposes IBM Z systems to a heap buffer overflow via a caller-controlled track range supplied to dasd_eckd_check_device_format(). The root cause is that fmt_buffer_size is declared as int while the buffer-size expression evaluates at size_t width, causing the result to be silently truncated on assignment; kzalloc() then allocates a buffer far smaller than needed, while the subsequent channel program builder operates on the untruncated track count and writes past the allocation. Systems running unpatched kernels before 6.6.151, 6.12.103, 6.18.44, 7.1.8, or 7.2 on s390 architecture face potential kernel heap corruption with consequences ranging from denial of service to local privilege escalation. No public exploit code exists and this vulnerability has not been added to the CISA KEV catalog at time of analysis.
Heap out-of-bounds memory access in the Linux kernel s390/zcrypt subsystem exposes EP11 crypto card administrative paths to local low-privileged users. The flaw resides in the domain value upper-limit check processed when sending EP11 CPRBs (Control Program Request Blocks) through custom zcrypt device nodes - the missing AP_DOMAINS (256) ceiling allows an attacker-supplied domain index to reach heap memory beyond the `perms->adm` structure. No public exploit code has been identified and this is not listed in CISA KEV, but the CVSS 7.8 local vector and confirmed multi-version patch backports across stable kernel branches indicate the Linux security team treats the impact as high. EPSS at 0.16% (6th percentile) reflects the platform-specific nature of the flaw.
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
Uninitialized receive buffer allocation in the Linux kernel's CAN J1939 transport layer exposes residual kernel heap memory to J1939 session participants. The function j1939_session_fresh_new() allocates a buffer without zeroing it, meaning any system running a CAN-capable Linux kernel with J1939 transport support may leak prior heap contents to peers exchanging Extended Transport Protocol (ETP) messages. No public exploit has been identified at time of analysis, and EPSS sits at 0.16% (6th percentile), consistent with a low-exploitation-probability kernel information-disclosure flaw in a specialized networking subsystem.
Out-of-bounds read and write vulnerabilities in the Linux kernel's softing CAN driver `fw_parse()` function allow a local low-privileged attacker to corrupt kernel DPRAM memory by supplying a crafted firmware image. Affected kernels span from 2.6.38 through pre-patch stable branches (5.10.x, 5.15.x, 6.1.x, 6.6.x, 6.12.x, 6.18.x, 7.1.x, and 7.2), with fixes backported across all active stable trees. No public exploit or active exploitation has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5)
Memory corruption in the Linux kernel's VMware graphics (vmwgfx) DRM driver allows a local, low-privileged user on a VMware guest system to corrupt MOB (Memory Object Buffer) allocation metadata, leading to out-of-bounds reads or writes with high confidentiality, integrity, and availability impact. A field-naming bug in vmwgfx_resource.c writes boolean literals (0/false and 1/true) to the guest_memory_size unsigned-long field instead of the adjacent guest_memory_dirty bitfield, causing subsequent size-dependent operations to compute zero-length or wrap-around memory ranges on the MOB bitmap. No public exploit has been identified at time of analysis; EPSS is very low at 0.17% (6th percentile), though the CVSS 7.8 score reflects meaningful severity if triggered locally on a VMware guest.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB.
Out-of-bounds memory corruption in the Linux kernel's vmwgfx DRM driver (vmw_external_bo_copy()) allows a local attacker with low-privilege DRM access to corrupt kernel memory via a crafted atomic display commit using an imported dma-buf framebuffer. Two distinct code paths are vulnerable: the equal-stride memcpy path suffers unsigned integer underflow when caller-supplied offsets exceed the buffer object size, and the non-equal-stride row-by-row path performs no bounds validation at all, allowing the copy loop to walk arbitrarily past the vmap end. Vendor-released patches are available across multiple stable kernel branches; no public exploit has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.
In the Linux kernel, the following vulnerability has been resolved: erofs: ensure valid f_path for page cache sharing Previously, backing files for page cache sharing were set up with f_path left as NULL (only f_inode was valid). It worked, but a recent mincore fix relies on f_path.mnt and crashes (found by "erofs/028" on 7.2-rc4): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 3 UID: 0 PID: 675528 Comm: fincore Not tainted 7.2.0-rc4-00002-g[]-dirty #1 PREEMPT(lazy) Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 RIP: 0010:__do_sys_mincore+0xc0/0x2c0 ... Specify valid paths using valid disconnected dentries together with erofs_ishare_mnt instead of leaving f_path empty, so they are more like real backing files in a pseudo filesystem and standard backing_file_open() can be used directly.
Out-of-bounds memory access in the Linux kernel's ltc4282 hwmon driver exposes systems with this hardware monitor to kernel memory disclosure or destabilization via the VGPIO minimum alarm voltage sysfs read path. A missing return statement in the driver causes the kernel to access memory beyond intended bounds when a local user reads the VGPIO channel's minimum alarm voltage attribute. Patch versions are available across multiple stable branches; no public exploit exists and EPSS sits at 0.17% (6th percentile), indicating very low current exploitation pressure despite the 7.8 CVSS score.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().
Denial of service in the Linux kernel's MediaTek mtk_eth_soc Ethernet driver: mtk_poll_controller() passed a net_device pointer to mtk_handle_irq_rx(), which expects a struct mtk_eth pointer (the value registered as the request_irq cookie). When CONFIG_NET_POLL_CONTROLLER is enabled and the ndo_poll_controller path is exercised (e.g. via netconsole/netpoll), the resulting bad-pointer dereference crashes the kernel. Only devices using the MediaTek SoC Ethernet driver are affected; there is no public exploit identified at time of analysis and EPSS is low (0.17%, 6th percentile).
Out-of-bounds slab write in the Linux kernel idpf network driver lets a malicious or compromised control plane (a PF or a hypervisor's device model) corrupt kernel heap memory during interrupt-vector setup. idpf_get_reg_intr_vecs() fills the reg_vals[] array bounded only by per-chunk num_vectors from a VIRTCHNL2_OP_ALLOC_VECTORS reply, which is never reconciled against the smaller num_allocated_vectors used to size the allocation, so a reply whose chunk counts sum higher writes struct idpf_vec_regs entries past the buffer. It carries a CVSS of 9.3, but EPSS is only 0.15%, it is not on CISA KEV, and there is no public exploit identified at time of analysis.
Use-after-free in the Linux kernel Bluetooth HCI sync subsystem exposes systems running vulnerable kernel versions (6.6.51-pre-6.7 and 6.8.9-pre-6.9) to potential kernel-context memory corruption from an adjacent attacker with no privileges required. The race condition occurs when hci_connect_acl/le_sync() callbacks dereference a freed hci_conn object during concurrent connection teardown, yielding a theoretical path to arbitrary code execution or kernel panic. No public exploit code has been identified at time of analysis, and EPSS at 0.15% (5th percentile) indicates very low observed exploitation activity.
Null pointer dereference in the Linux kernel's SCSI target iblock driver crashes the kernel when processing Persistent Reservation PREEMPT or RELEASE operations against storage backends with unimplemented PR hooks. Systems running the kernel as an iSCSI target are vulnerable - an attacker who can issue SCSI Persistent Reservation commands can trigger a kernel panic, causing a complete denial of service. No public exploit has been identified and EPSS sits at 0.17% (6th percentile), but patches are available across multiple stable branches and should be applied promptly on iSCSI target infrastructure.
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL pointer dereference in the device teardown path if ufs_rpmb_probe() fails.
In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().
In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen.
In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.
In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks.
Out-of-bounds vmemmap read in the Linux kernel's mm/util snapshot_page() crashes or leaks kernel memory during page isolation on memory-remove paths. The function incorrectly reads __page_2 when nr_pages > 1 rather than the correct threshold of nr_pages > 2, causing an illegal access into an adjacent, unmapped vmemmap section when an order-1 folio sits at a vmemmap section boundary. This was observed producing a kernel oops on ppc64le systems during DLPAR memory remove on a 22 TB LPAR. No public exploit is identified and EPSS is 0.17%, but the defect can cause a local denial-of-service or kernel memory disclosure. Patches are available across multiple stable kernel branches.
Denial-of-service in the Linux kernel's KVM subsystem on IBM Z (s390) mainframes stems from an unchecked airq_iv_create() return value in the zPCI adaptive-interrupt path. When AIBV allocation fails, zdev->aibv is left NULL and later dereferenced in kvm_zpci_set_airq(), crashing the host kernel. No public exploit identified at time of analysis and it is not in CISA KEV; EPSS is low at 0.17% (7th percentile), consistent with a hard-to-trigger, resource-exhaustion-dependent bug rather than a broadly weaponizable flaw.
Use-after-free in the Linux kernel Bluetooth SCO subsystem allows an adjacent unauthenticated attacker to corrupt freed kernel memory by exploiting a reference-counting race between socket close() and Bluetooth controller Disconnection Complete events. The race causes sco_conn_del() to perform a double put on a kref, confirmed by KASAN as slab-use-after-free, with potential to escalate privileges or crash the system. No public exploit or CISA KEV listing exists; EPSS is 0.17% (6th percentile), consistent with the race condition complexity limiting practical exploitation.
Incorrect unit conversion in the RISC-V memory management subsystem causes vmemmap_start_pfn to be computed with a physically misaligned base, violating the mask-alignment requirement for compound_info encoding in the sparse memory model. Linux kernel versions incorporating commit 476849b0fba4 on RISC-V hardware where DRAM base is not aligned to MAX_FOLIO_NR_PAGES × PAGE_SIZE are affected - a condition confirmed on QEMU virt machines and potentially other RISC-V platforms. CVSS 7.8 (AV:L/PR:L/C:H/I:H/A:H) reflects potential local privilege escalation via kernel memory corruption; EPSS of 0.17% (7th percentile) and no CISA KEV listing indicate no observed exploitation activity. No public exploit is identified at time of analysis.
Use-after-free in the Linux kernel's VXLAN transmit path (vxlan_xmit) lets a stale Ethernet header pointer be dereferenced after route_shortcircuit() calls pskb_may_pull() and reallocates skb->head, corrupting or reading freed memory when accessing eth->h_dest. The flaw affects systems using a VXLAN overlay interface and is most realistically a denial-of-service (kernel crash) with potential information disclosure; no public exploit identified at time of analysis and EPSS is low (0.18%). It is not listed in CISA KEV and no proof-of-concept is known.
Use-after-free in the Linux kernel's AMD MP2 I2C driver (i2c-amd-mp2) enables local low-privileged users to corrupt kernel memory, potentially achieving privilege escalation or system crash on AMD hardware. The flaw occurs during driver probe: when i2c_add_adapter() fails, devres frees the platform I2C context, but the MP2 PCI driver retains a stale pointer in its IRQ and system-sleep callback table, allowing subsequent dereference of freed memory. No public exploit exists and EPSS is 0.18% (7th percentile), reflecting the hardware-specific and error-path-dependent nature of this flaw; vendor-released patches are available across all major stable kernel branches.
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator.
Race condition and error-handling flaws in the i2c-imx I2C controller driver allow a NULL pointer dereference via the kernel interrupt handler on NXP i.MX SoC-based systems. The vulnerability affects multiple stable kernel branches (5.15 through 7.x) and is triggered when I2C slave registration fails partway through a PM runtime resume, leaving a stale or NULL pointer that the shared IRQ handler can dereference concurrently. The realistic impact is a kernel panic causing system unavailability; no public exploit exists and EPSS is 0.17%, consistent with no observed active exploitation.
Race condition in the Linux kernel's driver core `dev_has_sync_state()` exposes a TOCTOU (Time-of-Check Time-of-Use) flaw allowing local low-privileged users to potentially trigger kernel memory corruption, information disclosure, or a system crash. The function reads `dev->driver` twice without holding `device_lock()`, enabling a concurrent device unbind operation to clear the pointer between the NULL check and its subsequent dereference, resulting in use of a stale or NULL pointer in kernel context. No active exploitation has been identified (no CISA KEV listing, EPSS 0.18%), but the kernel-level impact class warrants prompt patching on affected stable branches.
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
The BPF signed loader in the Linux kernel fails to enforce map exclusivity before performing SHA-based integrity validation of metadata maps, allowing a local attacker with BPF privileges to race a mutation of the shared map's contents after the hash is computed but before validation completes. Systems running Linux kernel between commit fb2b0e290147ba01a53dfd92cf91058c9d2ee254 and the patched stable releases (6.18.40, 7.1.5, 7.2) are affected. Exploitation bypasses the integrity guarantees of the signed BPF loader, enabling the attacker to make the check pass on stale, attacker-controlled data; no public exploit exists and EPSS is 0.17% (6th percentile), indicating low current exploitation probability.
Out-of-bounds kernel memory reads in the Linux kernel's NTFS driver arise because ntfs_read_locked_inode() copies a resident $ATTRIBUTE_LIST into ni->attr_list via a plain memcpy() with no sanity checking, while only the non-resident path was ever validated by load_attribute_list(). A crafted NTFS volume with a malformed resident attribute list is then trusted by every subsequent walk (ntfs_external_attr_find(), ntfs_inode_attach_all_extents(), ntfs_attrlist_need()), which read fixed-header fields past the buffer. The fix factors per-entry validation into ntfs_attr_list_entry_is_valid()/ntfs_attr_list_is_valid() and applies it on the resident path and inside load_attribute_list() itself; no public exploit identified at time of analysis and EPSS probability is very low (0.15%).
Out-of-bounds slab read in the Linux kernel's legacy in-kernel NTFS driver lets a crafted on-disk $ATTRIBUTE_LIST leak or crash adjacent kernel heap memory when a malicious NTFS volume is mounted and read. The flaw is in ntfs_external_attr_find(), where a look-ahead attribute-list entry is dereferenced past the end of the kvmalloc'd buffer. There is no public exploit identified at time of analysis, EPSS risk is low (0.15%, 5th percentile), and it is not listed in CISA KEV.
Out-of-bounds kernel heap read in the Linux kernel's classic in-tree NTFS driver (`fs/ntfs/`) allows a local, low-privileged user to disclose kernel memory - and potentially chain to privilege escalation - by mounting a crafted NTFS image at the filesystem layer. The flaw is a u16 integer truncation in `ntfs_check_restart_area()` that silently defeats a page-size bounds check, causing `ntfs_check_log_client_array()` to dereference up to ~64 KiB beyond an allocated heap buffer using attacker-controlled on-disk values. No public exploit code exists and no active exploitation has been confirmed; EPSS is 0.15% (5th percentile), reflecting negligible observed exploitation pressure.
Heap and integer-overflow memory corruption in the Linux kernel's userspace perf tool (perf sched) lets a malicious perf.data file corrupt memory when parsed by register_pid(). An analyst who runs 'perf sched' against an attacker-supplied perf.data trace can trigger out-of-bounds heap writes, an unchecked strcpy into a 20-byte comm buffer, and denial of service, potentially leading to code execution in the context of the user running perf. A vendor fix is available; EPSS is low (0.18%) and there is no public exploit identified at time of analysis.
Out-of-bounds heap read in the Linux kernel's perf userspace tooling (perf tools) lets a crafted perf.data file trigger memory disclosure or a crash when parsed. The flaw sits in machine__resolve(), which trusts an attacker-controlled CPU index (al->cpu) from sample data and indexes env->cpu[] without validating it against env->nr_cpus_avail; a large index reads past the heap allocation, and values like 65536 truncate to int16_t and silently resolve to CPU 0. No public exploit is identified at time of analysis, and EPSS is low (0.18%, 7th percentile).
In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.
Use-after-free / stale-pointer race in the Linux kernel netfilter nf_conntrack_expect subsystem was resolved by replacing the per-expectation timer API with the conntrack garbage-collection worker. Under the old timer scheme, expectation removal could lose a race with an expiring timer (timer_del() returning false), leaving an expectation referencing an already-released exp->master conntrack, enabling stale-pointer access. The issue affects systems using connection-tracking helpers/expectations (e.g. FTP, SIP, or nft_ct expectations); no public exploit identified at time of analysis and it is not listed in CISA KEV, with a very low EPSS of 0.15% (5th percentile).
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---
Availability denial in the Linux kernel's KVM ARM64 nested virtualization stack allows a guest VM to crash the host through improper Synchronous External Abort (SEA) handling when Stage 1 translation resolves a Guest Frame Number outside configured memory slots. Affected systems must run a vulnerable Linux 6.16-era kernel on ARM64 hardware with KVM nested virtualization explicitly enabled; fixed versions are 6.18.40, 7.1.5, and 7.2. No public exploit exists and no active exploitation is confirmed; EPSS stands at 0.18% (7th percentile), reflecting the niche attack surface.
NULL pointer dereference in the Linux kernel netfilter subsystem's xt_nat module allows a local attacker with low privileges to crash the kernel by instantiating SNAT or DNAT targets through the nft_compat compatibility layer using an unsupported bridge family, triggering a NULL dereference in nf_nat_setup_info(). Multiple stable kernel branches from 5.10 through 7.x are affected across numerous long-term support trees. No public exploit has been identified at time of analysis, and EPSS probability is very low at 0.18% (7th percentile); critically, the description itself notes the original crash was already mitigated by a prior upstream commit, making this patch a defense-in-depth hardening measure rather than a primary fix.
Symlink-based file clobbering in the Linux kernel's intel-speed-select daemon allows a local low-privileged user to redirect root-process writes to an attacker-chosen file by pre-positioning a symlink at the daemon's fixed /tmp pidfile path. Affected systems are those running Linux 5.18 through unpatched 6.x and 7.x branches on Intel Speed Select Technology hardware with the daemon active. No public exploit is identified at time of analysis and EPSS is low (0.17%, 7th percentile), but the attack is mechanically simple and requires only a local shell account.
Kernel stack disclosure and potential denial-of-service affect Linux systems with CXL hardware due to an off-by-8 size constant in the CXL RAS capability subsystem introduced in Linux 6.2. A local user who can trigger a CXL AER uncorrectable error and read tracefs can obtain up to 448 bytes of adjacent kernel stack data - potentially including code pointers and sensitive in-flight values - from the tracefs ring buffer. No public exploit identified at time of analysis; EPSS at 0.17% (6th percentile) reflects the niche CXL hardware dependency and local-only attack vector.
Use-after-free in the Linux kernel's UFS (Universal Flash Storage) core tracing subsystem allows a local attacker with tracing access to trigger a kernel crash or potentially achieve privilege escalation. The UFS trace event infrastructure stores raw pointers to the `hba` (Host Bus Adapter) structure in the trace ring buffer, then dereferences those pointers inside `TP_printk()` when `/sys/kernel/tracing/trace` is read - which may occur long after the underlying UFS device has been detached and its memory freed. No public exploit has been identified at time of analysis, and EPSS is 0.17% (6th percentile), indicating low near-term exploitation probability despite the high CVSS score.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove() Attempting to access driver data in the platform driver ->remove() callback may lead to a null pointer dereference since there is no guaranty that the component ->bind() callback invoking platform_set_drvdata() was executed. A common scenario is when Rockchip DRM driver didn't manage to run component_bind_all() because of an (unrelated) error causing early return from rockchip_drm_bind(). Drop the unnecessary call to platform_get_drvdata() and, instead, reference the target device structure via platform_device.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer The management mailbox channel cleanup helpers can be called from error handling paths when mgmt_chann has already been destroyed. Add NULL checks to xdna_mailbox_free_channel() and xdna_mailbox_stop_channel() so the cleanup path safely returns instead of dereferencing a NULL mailbox channel pointer.
Uninitialized-value access in the Linux kernel's HFS+ filesystem driver allows a local attacker with mount privileges to trigger kernel memory corruption or information disclosure by supplying a crafted disk image containing an invalid btree node_size. The flaw is reached during the mount path - specifically in hfsplus_bnode_find() while loading the HFS+ catalog B-tree - when a corrupted node_size value (e.g., 1) causes an excessively large offset to be passed to hfs_bnode_read_u16(), resulting in use of uninitialized stack memory. No public exploit has been identified and EPSS is 0.15% (5th percentile); upstream stable patches are available at git.kernel.org.
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Fix race condition in event registration The zynqmp_power driver registers handlers for suspend and subsystem restart events using register_event(). However, the work structures (zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by these handlers were allocated and initialized after the registration call. This created a race window where, if the firmware triggered an event immediately after registration but before allocation, the callback (suspend_event_callback or subsystem_restart_event_callback) would dereference a NULL pointer in work_pending(), leading to a crash. Fix this by allocating and initializing the work structures before registering the events.
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.
Race condition in the Linux kernel's hisi_sas v3 hardware driver triggers a kernel WARNING and potential memory corruption when SAS phy link reset and driver removal (rmmod) execute simultaneously. Specifically, during SAS phy bring-up, device_links_driver_bound sets the link status to DL_STATE_AVAILABLE, and a concurrent rmmod then causes __device_links_no_driver() to encounter an inconsistent device-link state. No public exploit exists and EPSS sits at 0.17% (6th percentile), reflecting this is a hardware-specific, privilege-intensive, timing-dependent flaw with very low exploitation likelihood in practice.
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL dsm_create() initially checks pdev->bus when computing segment_id: u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0; But the next two lines unconditionally dereference pdev->bus via pcie_find_root_port() and especially pci_dev_id(pdev), which expands to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact NULL, segment_id is initialised to 0 but the very next statement crashes the kernel. smatch flags this: drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we previously assumed 'pdev->bus' could be null (see line 251) Make the NULL handling consistent: if pdev->bus is NULL the device has no PCI context to work with and SEV TIO setup cannot proceed, so return -ENODEV before any of the bus-dependent lookups. The remaining initialisation now runs only on the path where pdev->bus is known to be valid. No change for callers where pdev->bus is non-NULL, which is the only case where dsm_create() did meaningful work before this change.
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
Out-of-bounds memory access in the Linux kernel's ARM SCMI firmware subsystem allows a local low-privileged attacker on ARM-based hardware to trigger kernel memory corruption via the scmi_power_name_get() function, which fails to validate the domain number supplied by external callers. Affected kernel versions span from the introduction commit 76a6550990e2 through multiple stable branches, with patches backported to LTS lines 5.15, 6.1, 6.6, 6.12, and 6.18. No public exploit code has been identified at time of analysis, and EPSS probability is very low at 0.17% (7th percentile), indicating no current attacker tooling interest despite the 7.8 CVSS score.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18
NULL pointer dereference in the Linux kernel IPv6 subsystem - specifically in `__in6_dev_stats_get()` - can crash the kernel and cause a denial of service when a physical network device is unregistered while IPv6 statistics are being collected. The vulnerability affects a wide range of stable kernel branches, from 4.19 through 7.x, and has been patched across all active LTS trees. No active exploitation is confirmed (not in CISA KEV) and EPSS at 0.18% (7th percentile) reflects low current real-world exploitation interest, though the ubiquitous deployment of the Linux kernel makes patch cadence important.
Invalid pointer dereference in the Linux kernel's RapidIO TSI721 driver allows an unauthenticated attacker on an adjacent RapidIO network to crash the kernel or corrupt memory by sending a crafted doorbell message. The root cause is a logic error in tsi721_db_dpc(): the 'found' flag is not reset at the start of each list_for_each() iteration, causing every doorbell after the first match to be treated as found, and causing list-end traversal with an invalid iterator pointer when no match exists. No public exploit exists and EPSS is 0.18% (7th percentile), consistent with the highly constrained physical attack surface; patches are available across multiple stable kernel branches.
In the Linux kernel, the following vulnerability has been resolved: ocfs2: don't BUG_ON an invalid journal dinode [BUG] A fuzzed OCFS2 image can corrupt the current slot journal dinode while mount is still in progress. The mount path first reports the invalid journal block and then crashes in shutdown: kernel BUG at fs/ocfs2/journal.c:1034! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_journal_toggle_dirty+0x2d6/0x340 fs/ocfs2/journal.c:1034 Call Trace: ocfs2_journal_shutdown+0x414/0xc30 fs/ocfs2/journal.c:1116 ocfs2_mount_volume fs/ocfs2/super.c:1785 [inline] ocfs2_fill_super+0x30a9/0x3cd0 fs/ocfs2/super.c:1083 get_tree_bdev_flags+0x38b/0x640 fs/super.c:1698 get_tree_bdev+0x24/0x40 fs/super.c:1721 ocfs2_get_tree+0x21/0x30 fs/ocfs2/super.c:1184 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... [CAUSE] ocfs2_journal_toggle_dirty() used to return -EIO when journal->j_bh no longer contained a valid dinode, because the startup and shutdown paths already handled that failure. Commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") changed the check to a BUG_ON() under the assumption that the journal dinode had already been validated. That turns an unexpected invalid journal dinode during mount teardown into a kernel crash instead of a normal mount failure. [FIX] Replace the BUG_ON() with WARN_ON() and return -EIO. This keeps the invariant warning for debugging, but restores the original behavior of failing startup or shutdown cleanly instead of panicking the kernel.
In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.
In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.
In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]
In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ]
Out-of-bounds write in the Linux kernel's OCFS2 cluster filesystem driver corrupts adjacent kernel memory when a low-privileged user unlinks a refcounted file whose refcount tree contains leaf blocks, triggering a fortify panic on hardened kernels. The root cause is an incorrect memset bound in `ocfs2_remove_refcount_extent()` arising from a union aliasing issue between `rf_records.rl_count` and `rf_list.l_tree_depth`. No public exploit or active exploitation has been identified; EPSS is 0.15% (5th percentile) and the vulnerability does not appear in CISA KEV, reflecting low real-world exploitation risk at time of analysis.
Unaligned memory access in the Linux kernel netfilter synproxy timestamp adjustment code can crash the kernel or degrade performance on strict-alignment CPU architectures when synproxy is actively configured. Systems running synproxy as a SYN-flood mitigation layer on architectures such as SPARC, classic MIPS, or ARM without hardware unaligned-access emulation are exposed to remote-triggered denial of service via crafted TCP packets. No active exploitation is confirmed (absent from CISA KEV) and EPSS at 0.17% (6th percentile) indicates negligible observed exploitation probability, though the network-reachable vector warrants timely patching on vulnerable platforms.
In the Linux kernel, the following vulnerability has been resolved: net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header). However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skb_gro_receive(), leading to several issues: 1. skb_gro_receive() checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) includes mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check with p->mac_header < 8 bytes. When ipv6_gro_complete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->mac_header. 2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q / ETH_P_8021AD) to aggregate beyond 64KB because p->protocol != ETH_P_IPV6 was true. 3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB. Fix skb_gro_receive() to strictly enforce: - NAPI_GRO_CB(skb)->proto == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) - Protocol must be either ETH_P_IP or ETH_P_IPV6 - If ETH_P_IPV6, p->mac_header must be at least sizeof(struct hop_jumbo_hdr) Returning -E2BIG from skb_gro_receive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping. This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y.
Boot registry parameter injection in IGEL OS 12 (before 12.7.6) and IGEL OS 11 (before 11.11.150) allows an attacker with physical access to execute arbitrary Linux kernel command-line parameters by writing to an unencrypted, unsigned configuration partition that the signed bootloader reads at startup. The attack is particularly dangerous because it does not alter the measured boot code path, meaning TPM PCR attestation does not detect the tampering - effectively defeating the trust assumptions of the secure boot and full-disk encryption stack. A publicly available exploit script and a DEF CON 34 presentation detail the technique; no CISA KEV listing has been issued at time of analysis, indicating exploitation has not been confirmed at scale.
vmclock in the Linux kernel exposes a shared ABI memory page that a low-privileged guest process can upgrade from read-only to writable using mprotect(), allowing direct corruption of host-maintained timekeeping fields including sequence counters, UTC time, and TSC offsets. Affected deployments are virtualized Linux guests running kernels prior to patched stable releases 6.18.47, 7.2.1, and 7.1.11, where the vmclock miscdevice driver fails to clear VM_MAYWRITE on read-only mmap paths. No public exploit code has been identified at time of analysis, and EPSS at 0.15% (5th percentile) reflects low observed exploitation pressure despite a CVSS 8.8 score driven by the scope-changing guest-to-host integrity impact.
Out-of-bounds memory write in the Linux kernel's device tree reserved memory subsystem allows an attacker with control over device tree content to corrupt kernel memory at boot time, with theoretical full kernel compromise (C:H/I:H/A:H). The fdt_scan_reserved_mem() function writes past the end of a fixed-size local array when a device tree blob defines more dynamically-placed /reserved-memory subnodes than MAX_RESERVED_REGIONS allows. Despite a CVSS score of 8.4, exploitation is heavily constrained by the requirement to modify device tree content before boot - a capability requiring privileged firmware access - and EPSS at 0.16% (5th percentile) reflects negligible observed exploitation probability. No public exploit has been identified and the vulnerability is absent from CISA KEV.
Insufficient validation of S1G (802.11ah/Wi-Fi HaLow) Target Wake Time setup frames in the Linux kernel's mac80211 subsystem allows an unauthenticated adjacent-network attacker to submit a malformed individual TWT agreement whose parameter block is shorter than the full struct ieee80211_twt_params. The driver callback drv_add_twt_setup() and associated kernel tracepoint both consume the complete parameters structure regardless of the truncated length, potentially triggering kernel memory corruption, out-of-bounds reads exposing sensitive kernel memory, or a denial-of-service crash. No public exploit code has been identified, CISA KEV listing is absent, and patches are confirmed across seven stable kernel branches; real-world exposure is substantially narrowed by the requirement for S1G hardware.
Dangling pointer dereference in the Linux kernel Bluetooth ISO subsystem exposes systems running kernel versions prior to 6.18.44, 7.1.8, and 7.2 to potential kernel memory corruption from adjacent Bluetooth attackers. After iso_conn_del() is invoked, ISO sockets may continue to dereference the freed hcon (HCI connection) pointer due to imprecise reference-counting logic, creating a use-after-free-class condition in kernel space. Despite a high NVD CVSS score of 8.8, the EPSS rating of 0.15% (5th percentile) and absence from CISA KEV indicate no public exploit or observed active exploitation at time of analysis.
Deadlock in the Linux kernel's iomap subsystem allows local attackers to cause a denial of service by exhausting the shared bioset used by both iomap_split_ioend and its input bios. The circular dependency in bioset allocation halts I/O completion on iomap-backed filesystems (XFS, ext4 direct I/O) and can hang the affected system. No active exploitation has been confirmed (not in CISA KEV) and the EPSS probability is very low at 0.15% (5th percentile), but the impact on availability is total for the affected I/O path.
In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
Bitmap overflow and incorrect global accounting in the Linux kernel's percpu-km memory allocator (`mm/percpu-km`) allow a local low-privileged attacker on SMP/NUMA systems to corrupt kernel memory, with potential for privilege escalation or kernel crash. Two separate commits introduced the flaws: a63d4ac4ab609 caused `pcpu_create_chunk()` to write beyond the `chunk->populated` bitmap when `nr_units > 1`, and b539b87fed37f introduced the companion `pcpu_nr_empty_pop_pages` accounting error. Fixes have been backported to eight stable kernel branches (5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8, 7.2); no public exploit has been identified at time of analysis.
Out-of-bounds read in the Linux kernel SCTP subsystem leaks up to four bytes of receive-buffer tail memory to remote unauthenticated attackers via a malformed INIT chunk. When an Adaptation Layer Indication parameter is sent with only its 4-byte header (omitting the mandatory 32-bit Adaptation Code Point), the kernel reads past the declared parameter boundary and copies those bytes into the state cookie of the INIT ACK response, exposing them to the peer. No public exploit has been identified and EPSS of 0.16% (6th percentile) indicates low exploitation probability, though the unauthenticated, network-accessible attack surface on any SCTP-enabled system warrants prompt patching.
Use-after-free in the Linux kernel ALSA PCM subsystem allows a local low-privilege attacker to corrupt kernel memory by exploiting a race between snd_pcm_drain() and snd_pcm_unlink() on linked streams. When a drain wait terminates by signal or timeout while group membership is concurrently modified by an unlink, a stack-allocated wait queue entry is left queued on a freed peer stream's sleep list; a subsequent wake_up() call then dereferences that freed stack frame. No public exploit code or CISA KEV listing exists at time of analysis; the EPSS of 0.16% (6th percentile) reflects low near-term exploitation probability.
In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
Use-after-free in the Linux kernel's IPVS (IP Virtual Server) connection-synchronization path allows corruption of the connection hash table on backup directors running the IPVS sync daemon. When a synced connection is bound to a destination that carries the IP_VS_CONN_F_ONE_PACKET flag, expiry logic wrongly skips unlinking the conn_tab node, leaving a stale hash entry pointing at a freed struct ip_vs_conn. There is no public exploit identified at time of analysis and EPSS is very low (0.16%), so despite the auto-assigned 9.8 rating this is a memory-safety defect in a specialized load-balancing feature rather than a broadly weaponizable RCE.
Restriction bypass in the Linux kernel's io_uring subsystem allows a local low-privileged user to shed per-task io_uring security restrictions by executing exec(). When a task that has established io_uring restrictions calls exec(), the kernel's exec cancellation path invokes __io_uring_free(), which incorrectly frees both the task context and the per-task restriction simultaneously. Any io_uring ring created by the post-exec process is then entirely unrestricted, defeating sandbox and policy enforcement intended to constrain io_uring operations. No public exploit has been identified at time of analysis, but the CVSS score of 8.4 with Changed Scope (S:C) reflects that the bypass can expose confidentiality and integrity of resources guarded by the dropped restrictions.
The spi-qpic-snand NAND flash driver in Linux kernel 6.18 and later contains a command-ordering defect that causes every SET_FEATURE write to apply the previous operation's value rather than the intended one, producing an off-by-one effect. On Qualcomm IPQ5018-based hardware (confirmed on TP-Link Archer AX55 v1 with ESMT F50L1G41LB flash), this defect became destructive in v6.18 when SPI-NAND OTP support was introduced: the 'disable OTP mode' call erroneously leaves CFG_OTP_ENABLE set permanently, causing all subsequent flash reads to return OTP area content and all writes to fail with -EIO, rendering the device unbootable. No public exploit identified at time of analysis; EPSS of 0.15% (5th percentile) correctly reflects that this is a driver logic defect rather than a traditionally attacker-controllable vulnerability.
In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
Integer truncation in the Linux kernel s390/dasd ECKD driver exposes IBM Z systems to a heap buffer overflow via a caller-controlled track range supplied to dasd_eckd_check_device_format(). The root cause is that fmt_buffer_size is declared as int while the buffer-size expression evaluates at size_t width, causing the result to be silently truncated on assignment; kzalloc() then allocates a buffer far smaller than needed, while the subsequent channel program builder operates on the untruncated track count and writes past the allocation. Systems running unpatched kernels before 6.6.151, 6.12.103, 6.18.44, 7.1.8, or 7.2 on s390 architecture face potential kernel heap corruption with consequences ranging from denial of service to local privilege escalation. No public exploit code exists and this vulnerability has not been added to the CISA KEV catalog at time of analysis.
Heap out-of-bounds memory access in the Linux kernel s390/zcrypt subsystem exposes EP11 crypto card administrative paths to local low-privileged users. The flaw resides in the domain value upper-limit check processed when sending EP11 CPRBs (Control Program Request Blocks) through custom zcrypt device nodes - the missing AP_DOMAINS (256) ceiling allows an attacker-supplied domain index to reach heap memory beyond the `perms->adm` structure. No public exploit code has been identified and this is not listed in CISA KEV, but the CVSS 7.8 local vector and confirmed multi-version patch backports across stable kernel branches indicate the Linux security team treats the impact as high. EPSS at 0.16% (6th percentile) reflects the platform-specific nature of the flaw.
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
Uninitialized receive buffer allocation in the Linux kernel's CAN J1939 transport layer exposes residual kernel heap memory to J1939 session participants. The function j1939_session_fresh_new() allocates a buffer without zeroing it, meaning any system running a CAN-capable Linux kernel with J1939 transport support may leak prior heap contents to peers exchanging Extended Transport Protocol (ETP) messages. No public exploit has been identified at time of analysis, and EPSS sits at 0.16% (6th percentile), consistent with a low-exploitation-probability kernel information-disclosure flaw in a specialized networking subsystem.
Out-of-bounds read and write vulnerabilities in the Linux kernel's softing CAN driver `fw_parse()` function allow a local low-privileged attacker to corrupt kernel DPRAM memory by supplying a crafted firmware image. Affected kernels span from 2.6.38 through pre-patch stable branches (5.10.x, 5.15.x, 6.1.x, 6.6.x, 6.12.x, 6.18.x, 7.1.x, and 7.2), with fixes backported across all active stable trees. No public exploit or active exploitation has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5)
Memory corruption in the Linux kernel's VMware graphics (vmwgfx) DRM driver allows a local, low-privileged user on a VMware guest system to corrupt MOB (Memory Object Buffer) allocation metadata, leading to out-of-bounds reads or writes with high confidentiality, integrity, and availability impact. A field-naming bug in vmwgfx_resource.c writes boolean literals (0/false and 1/true) to the guest_memory_size unsigned-long field instead of the adjacent guest_memory_dirty bitfield, causing subsequent size-dependent operations to compute zero-length or wrap-around memory ranges on the MOB bitmap. No public exploit has been identified at time of analysis; EPSS is very low at 0.17% (6th percentile), though the CVSS 7.8 score reflects meaningful severity if triggered locally on a VMware guest.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB.
Out-of-bounds memory corruption in the Linux kernel's vmwgfx DRM driver (vmw_external_bo_copy()) allows a local attacker with low-privilege DRM access to corrupt kernel memory via a crafted atomic display commit using an imported dma-buf framebuffer. Two distinct code paths are vulnerable: the equal-stride memcpy path suffers unsigned integer underflow when caller-supplied offsets exceed the buffer object size, and the non-equal-stride row-by-row path performs no bounds validation at all, allowing the copy loop to walk arbitrarily past the vmap end. Vendor-released patches are available across multiple stable kernel branches; no public exploit has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.
In the Linux kernel, the following vulnerability has been resolved: erofs: ensure valid f_path for page cache sharing Previously, backing files for page cache sharing were set up with f_path left as NULL (only f_inode was valid). It worked, but a recent mincore fix relies on f_path.mnt and crashes (found by "erofs/028" on 7.2-rc4): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 3 UID: 0 PID: 675528 Comm: fincore Not tainted 7.2.0-rc4-00002-g[]-dirty #1 PREEMPT(lazy) Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 RIP: 0010:__do_sys_mincore+0xc0/0x2c0 ... Specify valid paths using valid disconnected dentries together with erofs_ishare_mnt instead of leaving f_path empty, so they are more like real backing files in a pseudo filesystem and standard backing_file_open() can be used directly.
Out-of-bounds memory access in the Linux kernel's ltc4282 hwmon driver exposes systems with this hardware monitor to kernel memory disclosure or destabilization via the VGPIO minimum alarm voltage sysfs read path. A missing return statement in the driver causes the kernel to access memory beyond intended bounds when a local user reads the VGPIO channel's minimum alarm voltage attribute. Patch versions are available across multiple stable branches; no public exploit exists and EPSS sits at 0.17% (6th percentile), indicating very low current exploitation pressure despite the 7.8 CVSS score.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().
Denial of service in the Linux kernel's MediaTek mtk_eth_soc Ethernet driver: mtk_poll_controller() passed a net_device pointer to mtk_handle_irq_rx(), which expects a struct mtk_eth pointer (the value registered as the request_irq cookie). When CONFIG_NET_POLL_CONTROLLER is enabled and the ndo_poll_controller path is exercised (e.g. via netconsole/netpoll), the resulting bad-pointer dereference crashes the kernel. Only devices using the MediaTek SoC Ethernet driver are affected; there is no public exploit identified at time of analysis and EPSS is low (0.17%, 6th percentile).
Out-of-bounds slab write in the Linux kernel idpf network driver lets a malicious or compromised control plane (a PF or a hypervisor's device model) corrupt kernel heap memory during interrupt-vector setup. idpf_get_reg_intr_vecs() fills the reg_vals[] array bounded only by per-chunk num_vectors from a VIRTCHNL2_OP_ALLOC_VECTORS reply, which is never reconciled against the smaller num_allocated_vectors used to size the allocation, so a reply whose chunk counts sum higher writes struct idpf_vec_regs entries past the buffer. It carries a CVSS of 9.3, but EPSS is only 0.15%, it is not on CISA KEV, and there is no public exploit identified at time of analysis.
Use-after-free in the Linux kernel Bluetooth HCI sync subsystem exposes systems running vulnerable kernel versions (6.6.51-pre-6.7 and 6.8.9-pre-6.9) to potential kernel-context memory corruption from an adjacent attacker with no privileges required. The race condition occurs when hci_connect_acl/le_sync() callbacks dereference a freed hci_conn object during concurrent connection teardown, yielding a theoretical path to arbitrary code execution or kernel panic. No public exploit code has been identified at time of analysis, and EPSS at 0.15% (5th percentile) indicates very low observed exploitation activity.
Null pointer dereference in the Linux kernel's SCSI target iblock driver crashes the kernel when processing Persistent Reservation PREEMPT or RELEASE operations against storage backends with unimplemented PR hooks. Systems running the kernel as an iSCSI target are vulnerable - an attacker who can issue SCSI Persistent Reservation commands can trigger a kernel panic, causing a complete denial of service. No public exploit has been identified and EPSS sits at 0.17% (6th percentile), but patches are available across multiple stable branches and should be applied promptly on iSCSI target infrastructure.
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL pointer dereference in the device teardown path if ufs_rpmb_probe() fails.
In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().
In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen.
In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.
In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks.
Out-of-bounds vmemmap read in the Linux kernel's mm/util snapshot_page() crashes or leaks kernel memory during page isolation on memory-remove paths. The function incorrectly reads __page_2 when nr_pages > 1 rather than the correct threshold of nr_pages > 2, causing an illegal access into an adjacent, unmapped vmemmap section when an order-1 folio sits at a vmemmap section boundary. This was observed producing a kernel oops on ppc64le systems during DLPAR memory remove on a 22 TB LPAR. No public exploit is identified and EPSS is 0.17%, but the defect can cause a local denial-of-service or kernel memory disclosure. Patches are available across multiple stable kernel branches.
Denial-of-service in the Linux kernel's KVM subsystem on IBM Z (s390) mainframes stems from an unchecked airq_iv_create() return value in the zPCI adaptive-interrupt path. When AIBV allocation fails, zdev->aibv is left NULL and later dereferenced in kvm_zpci_set_airq(), crashing the host kernel. No public exploit identified at time of analysis and it is not in CISA KEV; EPSS is low at 0.17% (7th percentile), consistent with a hard-to-trigger, resource-exhaustion-dependent bug rather than a broadly weaponizable flaw.
Use-after-free in the Linux kernel Bluetooth SCO subsystem allows an adjacent unauthenticated attacker to corrupt freed kernel memory by exploiting a reference-counting race between socket close() and Bluetooth controller Disconnection Complete events. The race causes sco_conn_del() to perform a double put on a kref, confirmed by KASAN as slab-use-after-free, with potential to escalate privileges or crash the system. No public exploit or CISA KEV listing exists; EPSS is 0.17% (6th percentile), consistent with the race condition complexity limiting practical exploitation.
Incorrect unit conversion in the RISC-V memory management subsystem causes vmemmap_start_pfn to be computed with a physically misaligned base, violating the mask-alignment requirement for compound_info encoding in the sparse memory model. Linux kernel versions incorporating commit 476849b0fba4 on RISC-V hardware where DRAM base is not aligned to MAX_FOLIO_NR_PAGES × PAGE_SIZE are affected - a condition confirmed on QEMU virt machines and potentially other RISC-V platforms. CVSS 7.8 (AV:L/PR:L/C:H/I:H/A:H) reflects potential local privilege escalation via kernel memory corruption; EPSS of 0.17% (7th percentile) and no CISA KEV listing indicate no observed exploitation activity. No public exploit is identified at time of analysis.
Use-after-free in the Linux kernel's VXLAN transmit path (vxlan_xmit) lets a stale Ethernet header pointer be dereferenced after route_shortcircuit() calls pskb_may_pull() and reallocates skb->head, corrupting or reading freed memory when accessing eth->h_dest. The flaw affects systems using a VXLAN overlay interface and is most realistically a denial-of-service (kernel crash) with potential information disclosure; no public exploit identified at time of analysis and EPSS is low (0.18%). It is not listed in CISA KEV and no proof-of-concept is known.
Use-after-free in the Linux kernel's AMD MP2 I2C driver (i2c-amd-mp2) enables local low-privileged users to corrupt kernel memory, potentially achieving privilege escalation or system crash on AMD hardware. The flaw occurs during driver probe: when i2c_add_adapter() fails, devres frees the platform I2C context, but the MP2 PCI driver retains a stale pointer in its IRQ and system-sleep callback table, allowing subsequent dereference of freed memory. No public exploit exists and EPSS is 0.18% (7th percentile), reflecting the hardware-specific and error-path-dependent nature of this flaw; vendor-released patches are available across all major stable kernel branches.
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator.
Race condition and error-handling flaws in the i2c-imx I2C controller driver allow a NULL pointer dereference via the kernel interrupt handler on NXP i.MX SoC-based systems. The vulnerability affects multiple stable kernel branches (5.15 through 7.x) and is triggered when I2C slave registration fails partway through a PM runtime resume, leaving a stale or NULL pointer that the shared IRQ handler can dereference concurrently. The realistic impact is a kernel panic causing system unavailability; no public exploit exists and EPSS is 0.17%, consistent with no observed active exploitation.
Race condition in the Linux kernel's driver core `dev_has_sync_state()` exposes a TOCTOU (Time-of-Check Time-of-Use) flaw allowing local low-privileged users to potentially trigger kernel memory corruption, information disclosure, or a system crash. The function reads `dev->driver` twice without holding `device_lock()`, enabling a concurrent device unbind operation to clear the pointer between the NULL check and its subsequent dereference, resulting in use of a stale or NULL pointer in kernel context. No active exploitation has been identified (no CISA KEV listing, EPSS 0.18%), but the kernel-level impact class warrants prompt patching on affected stable branches.
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
The BPF signed loader in the Linux kernel fails to enforce map exclusivity before performing SHA-based integrity validation of metadata maps, allowing a local attacker with BPF privileges to race a mutation of the shared map's contents after the hash is computed but before validation completes. Systems running Linux kernel between commit fb2b0e290147ba01a53dfd92cf91058c9d2ee254 and the patched stable releases (6.18.40, 7.1.5, 7.2) are affected. Exploitation bypasses the integrity guarantees of the signed BPF loader, enabling the attacker to make the check pass on stale, attacker-controlled data; no public exploit exists and EPSS is 0.17% (6th percentile), indicating low current exploitation probability.
Out-of-bounds kernel memory reads in the Linux kernel's NTFS driver arise because ntfs_read_locked_inode() copies a resident $ATTRIBUTE_LIST into ni->attr_list via a plain memcpy() with no sanity checking, while only the non-resident path was ever validated by load_attribute_list(). A crafted NTFS volume with a malformed resident attribute list is then trusted by every subsequent walk (ntfs_external_attr_find(), ntfs_inode_attach_all_extents(), ntfs_attrlist_need()), which read fixed-header fields past the buffer. The fix factors per-entry validation into ntfs_attr_list_entry_is_valid()/ntfs_attr_list_is_valid() and applies it on the resident path and inside load_attribute_list() itself; no public exploit identified at time of analysis and EPSS probability is very low (0.15%).
Out-of-bounds slab read in the Linux kernel's legacy in-kernel NTFS driver lets a crafted on-disk $ATTRIBUTE_LIST leak or crash adjacent kernel heap memory when a malicious NTFS volume is mounted and read. The flaw is in ntfs_external_attr_find(), where a look-ahead attribute-list entry is dereferenced past the end of the kvmalloc'd buffer. There is no public exploit identified at time of analysis, EPSS risk is low (0.15%, 5th percentile), and it is not listed in CISA KEV.
Out-of-bounds kernel heap read in the Linux kernel's classic in-tree NTFS driver (`fs/ntfs/`) allows a local, low-privileged user to disclose kernel memory - and potentially chain to privilege escalation - by mounting a crafted NTFS image at the filesystem layer. The flaw is a u16 integer truncation in `ntfs_check_restart_area()` that silently defeats a page-size bounds check, causing `ntfs_check_log_client_array()` to dereference up to ~64 KiB beyond an allocated heap buffer using attacker-controlled on-disk values. No public exploit code exists and no active exploitation has been confirmed; EPSS is 0.15% (5th percentile), reflecting negligible observed exploitation pressure.
Heap and integer-overflow memory corruption in the Linux kernel's userspace perf tool (perf sched) lets a malicious perf.data file corrupt memory when parsed by register_pid(). An analyst who runs 'perf sched' against an attacker-supplied perf.data trace can trigger out-of-bounds heap writes, an unchecked strcpy into a 20-byte comm buffer, and denial of service, potentially leading to code execution in the context of the user running perf. A vendor fix is available; EPSS is low (0.18%) and there is no public exploit identified at time of analysis.
Out-of-bounds heap read in the Linux kernel's perf userspace tooling (perf tools) lets a crafted perf.data file trigger memory disclosure or a crash when parsed. The flaw sits in machine__resolve(), which trusts an attacker-controlled CPU index (al->cpu) from sample data and indexes env->cpu[] without validating it against env->nr_cpus_avail; a large index reads past the heap allocation, and values like 65536 truncate to int16_t and silently resolve to CPU 0. No public exploit is identified at time of analysis, and EPSS is low (0.18%, 7th percentile).
In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.
Use-after-free / stale-pointer race in the Linux kernel netfilter nf_conntrack_expect subsystem was resolved by replacing the per-expectation timer API with the conntrack garbage-collection worker. Under the old timer scheme, expectation removal could lose a race with an expiring timer (timer_del() returning false), leaving an expectation referencing an already-released exp->master conntrack, enabling stale-pointer access. The issue affects systems using connection-tracking helpers/expectations (e.g. FTP, SIP, or nft_ct expectations); no public exploit identified at time of analysis and it is not listed in CISA KEV, with a very low EPSS of 0.15% (5th percentile).
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---
Availability denial in the Linux kernel's KVM ARM64 nested virtualization stack allows a guest VM to crash the host through improper Synchronous External Abort (SEA) handling when Stage 1 translation resolves a Guest Frame Number outside configured memory slots. Affected systems must run a vulnerable Linux 6.16-era kernel on ARM64 hardware with KVM nested virtualization explicitly enabled; fixed versions are 6.18.40, 7.1.5, and 7.2. No public exploit exists and no active exploitation is confirmed; EPSS stands at 0.18% (7th percentile), reflecting the niche attack surface.
NULL pointer dereference in the Linux kernel netfilter subsystem's xt_nat module allows a local attacker with low privileges to crash the kernel by instantiating SNAT or DNAT targets through the nft_compat compatibility layer using an unsupported bridge family, triggering a NULL dereference in nf_nat_setup_info(). Multiple stable kernel branches from 5.10 through 7.x are affected across numerous long-term support trees. No public exploit has been identified at time of analysis, and EPSS probability is very low at 0.18% (7th percentile); critically, the description itself notes the original crash was already mitigated by a prior upstream commit, making this patch a defense-in-depth hardening measure rather than a primary fix.
Symlink-based file clobbering in the Linux kernel's intel-speed-select daemon allows a local low-privileged user to redirect root-process writes to an attacker-chosen file by pre-positioning a symlink at the daemon's fixed /tmp pidfile path. Affected systems are those running Linux 5.18 through unpatched 6.x and 7.x branches on Intel Speed Select Technology hardware with the daemon active. No public exploit is identified at time of analysis and EPSS is low (0.17%, 7th percentile), but the attack is mechanically simple and requires only a local shell account.
Kernel stack disclosure and potential denial-of-service affect Linux systems with CXL hardware due to an off-by-8 size constant in the CXL RAS capability subsystem introduced in Linux 6.2. A local user who can trigger a CXL AER uncorrectable error and read tracefs can obtain up to 448 bytes of adjacent kernel stack data - potentially including code pointers and sensitive in-flight values - from the tracefs ring buffer. No public exploit identified at time of analysis; EPSS at 0.17% (6th percentile) reflects the niche CXL hardware dependency and local-only attack vector.
Use-after-free in the Linux kernel's UFS (Universal Flash Storage) core tracing subsystem allows a local attacker with tracing access to trigger a kernel crash or potentially achieve privilege escalation. The UFS trace event infrastructure stores raw pointers to the `hba` (Host Bus Adapter) structure in the trace ring buffer, then dereferences those pointers inside `TP_printk()` when `/sys/kernel/tracing/trace` is read - which may occur long after the underlying UFS device has been detached and its memory freed. No public exploit has been identified at time of analysis, and EPSS is 0.17% (6th percentile), indicating low near-term exploitation probability despite the high CVSS score.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove() Attempting to access driver data in the platform driver ->remove() callback may lead to a null pointer dereference since there is no guaranty that the component ->bind() callback invoking platform_set_drvdata() was executed. A common scenario is when Rockchip DRM driver didn't manage to run component_bind_all() because of an (unrelated) error causing early return from rockchip_drm_bind(). Drop the unnecessary call to platform_get_drvdata() and, instead, reference the target device structure via platform_device.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer The management mailbox channel cleanup helpers can be called from error handling paths when mgmt_chann has already been destroyed. Add NULL checks to xdna_mailbox_free_channel() and xdna_mailbox_stop_channel() so the cleanup path safely returns instead of dereferencing a NULL mailbox channel pointer.
Uninitialized-value access in the Linux kernel's HFS+ filesystem driver allows a local attacker with mount privileges to trigger kernel memory corruption or information disclosure by supplying a crafted disk image containing an invalid btree node_size. The flaw is reached during the mount path - specifically in hfsplus_bnode_find() while loading the HFS+ catalog B-tree - when a corrupted node_size value (e.g., 1) causes an excessively large offset to be passed to hfs_bnode_read_u16(), resulting in use of uninitialized stack memory. No public exploit has been identified and EPSS is 0.15% (5th percentile); upstream stable patches are available at git.kernel.org.
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Fix race condition in event registration The zynqmp_power driver registers handlers for suspend and subsystem restart events using register_event(). However, the work structures (zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by these handlers were allocated and initialized after the registration call. This created a race window where, if the firmware triggered an event immediately after registration but before allocation, the callback (suspend_event_callback or subsystem_restart_event_callback) would dereference a NULL pointer in work_pending(), leading to a crash. Fix this by allocating and initializing the work structures before registering the events.
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.
Race condition in the Linux kernel's hisi_sas v3 hardware driver triggers a kernel WARNING and potential memory corruption when SAS phy link reset and driver removal (rmmod) execute simultaneously. Specifically, during SAS phy bring-up, device_links_driver_bound sets the link status to DL_STATE_AVAILABLE, and a concurrent rmmod then causes __device_links_no_driver() to encounter an inconsistent device-link state. No public exploit exists and EPSS sits at 0.17% (6th percentile), reflecting this is a hardware-specific, privilege-intensive, timing-dependent flaw with very low exploitation likelihood in practice.
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL dsm_create() initially checks pdev->bus when computing segment_id: u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0; But the next two lines unconditionally dereference pdev->bus via pcie_find_root_port() and especially pci_dev_id(pdev), which expands to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact NULL, segment_id is initialised to 0 but the very next statement crashes the kernel. smatch flags this: drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we previously assumed 'pdev->bus' could be null (see line 251) Make the NULL handling consistent: if pdev->bus is NULL the device has no PCI context to work with and SEV TIO setup cannot proceed, so return -ENODEV before any of the bus-dependent lookups. The remaining initialisation now runs only on the path where pdev->bus is known to be valid. No change for callers where pdev->bus is non-NULL, which is the only case where dsm_create() did meaningful work before this change.
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
Out-of-bounds memory access in the Linux kernel's ARM SCMI firmware subsystem allows a local low-privileged attacker on ARM-based hardware to trigger kernel memory corruption via the scmi_power_name_get() function, which fails to validate the domain number supplied by external callers. Affected kernel versions span from the introduction commit 76a6550990e2 through multiple stable branches, with patches backported to LTS lines 5.15, 6.1, 6.6, 6.12, and 6.18. No public exploit code has been identified at time of analysis, and EPSS probability is very low at 0.17% (7th percentile), indicating no current attacker tooling interest despite the 7.8 CVSS score.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18
NULL pointer dereference in the Linux kernel IPv6 subsystem - specifically in `__in6_dev_stats_get()` - can crash the kernel and cause a denial of service when a physical network device is unregistered while IPv6 statistics are being collected. The vulnerability affects a wide range of stable kernel branches, from 4.19 through 7.x, and has been patched across all active LTS trees. No active exploitation is confirmed (not in CISA KEV) and EPSS at 0.18% (7th percentile) reflects low current real-world exploitation interest, though the ubiquitous deployment of the Linux kernel makes patch cadence important.
Invalid pointer dereference in the Linux kernel's RapidIO TSI721 driver allows an unauthenticated attacker on an adjacent RapidIO network to crash the kernel or corrupt memory by sending a crafted doorbell message. The root cause is a logic error in tsi721_db_dpc(): the 'found' flag is not reset at the start of each list_for_each() iteration, causing every doorbell after the first match to be treated as found, and causing list-end traversal with an invalid iterator pointer when no match exists. No public exploit exists and EPSS is 0.18% (7th percentile), consistent with the highly constrained physical attack surface; patches are available across multiple stable kernel branches.
In the Linux kernel, the following vulnerability has been resolved: ocfs2: don't BUG_ON an invalid journal dinode [BUG] A fuzzed OCFS2 image can corrupt the current slot journal dinode while mount is still in progress. The mount path first reports the invalid journal block and then crashes in shutdown: kernel BUG at fs/ocfs2/journal.c:1034! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_journal_toggle_dirty+0x2d6/0x340 fs/ocfs2/journal.c:1034 Call Trace: ocfs2_journal_shutdown+0x414/0xc30 fs/ocfs2/journal.c:1116 ocfs2_mount_volume fs/ocfs2/super.c:1785 [inline] ocfs2_fill_super+0x30a9/0x3cd0 fs/ocfs2/super.c:1083 get_tree_bdev_flags+0x38b/0x640 fs/super.c:1698 get_tree_bdev+0x24/0x40 fs/super.c:1721 ocfs2_get_tree+0x21/0x30 fs/ocfs2/super.c:1184 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... [CAUSE] ocfs2_journal_toggle_dirty() used to return -EIO when journal->j_bh no longer contained a valid dinode, because the startup and shutdown paths already handled that failure. Commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") changed the check to a BUG_ON() under the assumption that the journal dinode had already been validated. That turns an unexpected invalid journal dinode during mount teardown into a kernel crash instead of a normal mount failure. [FIX] Replace the BUG_ON() with WARN_ON() and return -EIO. This keeps the invariant warning for debugging, but restores the original behavior of failing startup or shutdown cleanly instead of panicking the kernel.
In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.
In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.
In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]
In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ]
Out-of-bounds write in the Linux kernel's OCFS2 cluster filesystem driver corrupts adjacent kernel memory when a low-privileged user unlinks a refcounted file whose refcount tree contains leaf blocks, triggering a fortify panic on hardened kernels. The root cause is an incorrect memset bound in `ocfs2_remove_refcount_extent()` arising from a union aliasing issue between `rf_records.rl_count` and `rf_list.l_tree_depth`. No public exploit or active exploitation has been identified; EPSS is 0.15% (5th percentile) and the vulnerability does not appear in CISA KEV, reflecting low real-world exploitation risk at time of analysis.
Unaligned memory access in the Linux kernel netfilter synproxy timestamp adjustment code can crash the kernel or degrade performance on strict-alignment CPU architectures when synproxy is actively configured. Systems running synproxy as a SYN-flood mitigation layer on architectures such as SPARC, classic MIPS, or ARM without hardware unaligned-access emulation are exposed to remote-triggered denial of service via crafted TCP packets. No active exploitation is confirmed (absent from CISA KEV) and EPSS at 0.17% (6th percentile) indicates negligible observed exploitation probability, though the network-reachable vector warrants timely patching on vulnerable platforms.