Suse
Monthly
Unauthenticated remote connection flooding against the cockpit-tls front-end of Cockpit (the TLS terminator for the Cockpit web console, default TCP 9090) forces the service to spawn an unbounded number of detached threads, exhausting memory and file descriptors until the console degrades or becomes unavailable. The flaw, tracked as CWE-770 (allocation of resources without limits or throttling), carries a 7.5 CVSS score (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects Cockpit as shipped in Red Hat Enterprise Linux 7, 8, 9, and 10 as well as Red Hat OpenShift Dev Spaces; the CVSS vector confirms the attack needs no authentication or user interaction. Exploitation is bounded to availability of the management console rather than the underlying host services, CISA's SSVC assessment records Exploitation: none (automatable: yes, technical impact: partial), and no public exploit code was identified at time of analysis. Because the primitive is simply 'open many concurrent TCP connections,' it is highly automatable and becomes a practical risk anywhere port 9090 is reachable from an untrusted network.
Memory exhaustion in the adm-zip Node.js library before 0.6.1 allows remote, unauthenticated attackers to crash or severely degrade any service that reads entries from untrusted ZIP archives: a 105-byte crafted archive whose central directory declares an uncompressed size of ~1.77 GB forces the library to commit roughly 1.8 GB of resident memory before validation fails, which OOM-kills memory-constrained processes (containers, serverless, small VMs) and, with concurrency, can exhaust larger hosts. Publicly available exploit code exists - the vendor advisory includes a self-contained 105-byte base64 PoC (sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386) - and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms a network-reachable availability-only impact with no privileges or user interaction required. There is no indication of confirmed active exploitation (not in CISA KEV), and applications that never parse attacker-controlled ZIPs are not exposed; the practical severity is governed by host memory limits rather than by any authentication or configuration bar.
Denial of service in libheif 1.23.1 and earlier: decoding a crafted HEIF/AVIF file whose derived-image reference graph (grid, iovl, or iden items) points many branches at a common base image causes the decoder to re-decode that base image repeatedly, exhausting CPU and, depending on tile handling, memory. The flaw is unauthenticated and remotely triggerable (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) against any service that automatically decodes attacker-supplied files - upload pipelines, thumbnailers, and transcoders are the highest-value targets - while desktop viewers require the user to open the file, effectively adding user interaction. Impact is availability-only (no code execution, disclosure, or modification), and no public exploit code was identified at time of analysis, though the weaponized input is a small, trivially constructed file. Vendor-released patch: 1.23.2.
Denial of service in libheif 1.19.0 through 1.23.1 allows unauthenticated remote attackers to exhaust process memory and terminate the application by supplying a crafted HEIF or AVIF file whose compressed mime metadata or unci image data is decompressed without an effective output bound. According to the CVSS vector (AV:N/AC:L/PR:N/UI:N) no privileges or interaction are required, so automated server-side image ingestion pipelines that parse untrusted HEIF/AVIF content are the most exposed; interactive desktop viewers still require a user to open the malicious file. Impact is availability-only (crash/OOM, no code execution or data disclosure), no public exploit code has been identified at time of analysis, and the issue is fixed in libheif 1.23.2.
Denial of service in uri-js through 4.4.1 lets remote, unauthenticated attackers stall a Node.js process indefinitely: the removeDotSegments routine enters an infinite loop when a path segment begins with a Unicode line separator (U+2028) or paragraph separator (U+2029), blocking the event loop until heap exhaustion. The package is an unmaintained, widely pulled-in dependency (commonly transitively, e.g. via ajv), so the risk is driven by prevalence: no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status. Exposure is limited to applications that actually route untrusted input into removeDotSegments directly, or into normalize()/resolve() with IRI handling enabled; code paths handling only trusted or internal URIs are not reachable by this bug.
Unauthenticated memory exhaustion in SGLang through 0.5.19 lets remote attackers force out-of-memory termination of the prefill process by submitting arbitrary bootstrap_room values to the decode engine's POST /generate endpoint. The flaw only manifests in a non-default deployment: prefill/decode disaggregation mode with the Mooncake KV transfer backend enabled, which is not the standard monolithic serving configuration, and the endpoint must be network-reachable. No public exploit code was identified at time of analysis, and the vulnerability is not confirmed actively exploited (CISA KEV); impact is confined to availability (CVSS 4.0 base 8.7; independent assessment scores the same issue 7.5 under CVSS 3.1), with no data exposure or code execution.
SMTP command injection in Netty's netty-codec-smtp allows unauthenticated remote attackers to inject arbitrary SMTP commands via CRLF sequences in the command-name field, affecting applications built on Netty such as Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7. This is an incomplete fix of CVE-2025-59419, requiring attacker-controlled input to reach the SMTP command name and a downstream SMTP server that acts on smuggled commands; no public exploit identified at time of analysis. Integrity impact is high, while confidentiality and availability are unaffected.
hickory-resolver releases before 0.26.2 fail to propagate a 'bogus' DNSSEC proof state out of the high-level Resolver::lookup() and Resolver::lookup_ip() APIs, so records that fail DNSSEC signature validation are handed back to the caller as successful, apparently validated answers. This is an integrity-only bypass affecting unauthenticated remote attackers (CVSS:4.0 8.7 / assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) who either control the authoritative zone answering the query or sit on the network path to inject forged records with invalid RRSIGs; applications that do not compile the crate's __dnssec feature are unaffected because they never expected validation in the first place. A vendor fix is available in 0.26.2 (commit 30720f4, PR 3871), and no public exploit code or confirmed active exploitation was observed at time of analysis. This is a genuine, high-priority integrity flaw despite the absence of exploitation telemetry.
Denial of service in Red Hat's Camel-based and Java middleware products (Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7): a STOMP frame that declares an oversized content-length is truncated from a 64-bit long to a 32-bit integer, yielding a wrapped/negative length that leaves the STOMP decoder unable to advance, so it loops indefinitely and burns CPU on the affected message-processing thread. The flaw is remotely reachable and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but exposure is strictly limited to deployments that actually enable a network-reachable STOMP listener - products without a configured STOMP endpoint are not attackable. No confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis.
Denial of service in rustls-webpki through 0.103.12 and in 0.104.0-alpha.1 through 0.104.0-alpha.6: a crafted certificate revocation list carrying an issuingDistributionPoint extension whose onlySomeReasons BIT STRING content is exactly [0x00] triggers an integer underflow in bit_string_flags() and panics the parsing process. Unauthenticated remote attackers can reach this only where an application has explicitly opted into CRL revocation checking by passing RevocationOptions to verify_for_usage() and parses CRL bytes from a source the attacker can influence (for example an attacker-supplied or MITM'd CRL distribution point); the default rustls configuration that omits RevocationOptions is unaffected. Publicly available exploit code exists - the GHSA-82j2-j2ch-gfr8 advisory ships a complete PoC CRL that reproduces the crash - but there is no confirmation of active exploitation, and the impact is purely availability (no confidentiality or integrity effect).
Privileged users inside a QEMU guest running on the Q35 machine type with the KVM accelerator can abuse the VAPIC setup hypercall (hw/i386/vapic.c) to break SMM isolation, because the code fails to verify that a writable RAM alias stays inside the option ROM window. By repositioning that alias over chipset-locked SMRAM, an attacker with root-equivalent guest access defeats D_LCK protection and injects code into System Management Mode memory, which QEMU scores as a scope-changing, total-impact compromise (CVSS 8.2). Exploitation is local to the guest with high privileges required (AV:L, PR:H, S:C), publicly available exploit code exists according to the CISA SSVC assessment, but there is no confirmed active exploitation and EPSS is low at 0.20% (10th percentile).
Unauthenticated remote attackers can cause a gradual denial of service in applications that use Netty's STOMP codec by sending a STOMP frame body without the terminating null byte; StompSubframeDecoder leaks a ByteBuf for each such frame, so sustained traffic exhausts JVM heap or direct memory. The issue carries CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning network-reachable, no authentication or user interaction, availability-only impact. Red Hat middleware products listed in CPE data are affected when STOMP-over-TCP/WebSocket is enabled; no public exploit code or confirmed active exploitation was identified at time of analysis, and a practical DoS requires repeated frames rather than a single packet.
Use-after-free code execution in PDFium, Chrome's bundled PDF rendering engine, allows a remote attacker who lures a victim into opening a crafted HTML page to run arbitrary code inside Chrome's renderer sandbox on any build prior to 153.0.8010.52. The bug is network-reachable and low-complexity with no authentication required, but it does require user interaction (the victim must navigate to the attacker-supplied page), and because the CVSS scope is unchanged (S:U) the compromise is contained within the renderer - full system takeover would require chaining a separate sandbox-escape flaw. Google has released a fixed build and there is no public exploit identified at time of analysis, though the CVSS 8.8 score and memory-corruption tag make timely patching advisable.
Heap buffer overflow in PDFium, the PDF rendering engine built into Google Chrome, allows a remote attacker to potentially execute arbitrary code inside the Chrome renderer sandbox on Windows systems running versions prior to 153.0.8010.52. Exploitation requires the victim to open an attacker-supplied crafted PDF (UI:R), so the attack is delivered via social engineering rather than direct network exploitation; no credentials are needed (PR:N) and default Chrome installations render PDFs without any special configuration. The vendor rates this High severity with a CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), and although a vendor patch is available, no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). Because code execution is confined to the renderer sandbox, full host compromise would additionally require a separate sandbox-escape vulnerability not covered by this advisory.
Type confusion in the V8 JavaScript engine of Google Chrome prior to 153.0.8010.52 allows remote, unauthenticated attackers to execute arbitrary code inside the renderer sandbox when a victim is socially engineered into loading a crafted HTML page (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Exploitation is not automatic: it requires user interaction, and because the resulting code execution is confined to the renderer sandbox, turning it into host-level compromise would require chaining a separate sandbox-escape vulnerability. There is no public exploit code identified at time of analysis and the flaw is not listed in CISA KEV, but a vendor patch (Chrome 153.0.8010.52) is available and this is a patch-now item for a ubiquitous product.
Local sandbox escape in Google Chrome on Windows (versions prior to 153.0.8010.52) lets an attacker who can already execute a program on the target host run arbitrary code outside the browser sandbox by abusing incorrect reference resolution in Chrome's Tracing component (CWE-706). The vendor rates it High with a CVSS of 8.1 (AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H), meaning exploitation is local-only, requires no user interaction, but is gated by high attack complexity - consistent with a race or timing-dependent condition that is not reliably repeatable. No public exploit code has been identified at time of analysis, and because a local foothold is a prerequisite, this is realistically a chained sandbox-escape stage rather than a standalone initial-access vulnerability.
Use-after-free in the Dawn (WebGPU) component of Google Chrome on Android before 153.0.8010.52 allows a remote, unauthenticated attacker to potentially execute arbitrary code outside the browser sandbox when a victim renders a crafted HTML page. Exploitation requires the user to load attacker-controlled content (CVSS 9.6, AV:N/AC:L/PR:N/UI:R), and Google rates the bug Chromium security severity Critical; the only affected configuration is Chrome on Android below the fixed 153.0.8010.52 build, and devices already updated are not exposed. There is no CISA KEV listing and no public exploit identified at time of analysis, so the practical risk is driven by the size of the unpatched Android install base rather than by observed attacks.
Use-after-free in Google Chrome's Extensions component allows a remote attacker to execute arbitrary code outside the browser sandbox on any desktop build prior to 153.0.8010.52, provided the victim loads a crafted, attacker-controlled extension. The flaw carries a 9.6 CVSS score (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), meaning no prior authentication to the target is needed, but the attacker must still persuade the user to install or load a malicious extension, which is the real-world limiting factor; the sandbox-scope change (S:C) reflects code execution escaping Chrome's renderer/extensions sandbox. A vendor patch shipping in 153.0.8010.52 is available, and no public exploit code or confirmed active exploitation has been identified at time of analysis. Because Chrome auto-updates aggressively, the exposed population shrinks quickly once the fixed build propagates.
Remote code execution outside the browser sandbox in Google Chrome on Android prior to 153.0.8010.52 is possible when a victim opens a crafted HTML page containing malicious WebGL content that triggers a stack-based buffer overflow. Unauthenticated remote attackers can achieve code execution in the context of the GPU/renderer process with high impact to confidentiality, integrity, and availability, though exploitation requires user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, 9.6, Chromium security severity Critical). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; Google has released a fixed build (153.0.8010.52) and the flaw is tracked as EUVD-2026-82476 and VulDB 407131.
Symlink-based archive extraction in Grafana OSS and Grafana Enterprise lets a malicious plugin archive write arbitrary files - including an executable backend binary - outside the plugin installation directory, and that binary then runs with the Grafana server process's privileges, yielding remote code execution. Exploitation is gated on a Grafana operator installing a plugin from an attacker-influenced archive (via the plugin catalog, grafana-cli, GF_INSTALL_PLUGINS, or preinstall configuration), which is the UI:R component of the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H vector; there is no unattended remote trigger against a running server. A key aggravating factor is that plugin archives are extracted before their signature is verified, so enforcing signed plugins does not mitigate this issue, and Grafana Enterprise carries the identical extraction code. No public exploit code has been identified at time of analysis, and the vulnerability is not in CISA KEV; independent assessment rates this a genuine high-priority issue rather than a high-CVSS-but-low-real-risk paper cut.
Stored cross-site scripting in Grafana's Geomap panel allows an authenticated user holding at least the Editor role to embed a malicious MapLibre base-layer style configuration whose attacker-controlled JavaScript executes in the browser session of any other user who views the panel, including an Org Admin, enabling privilege escalation to Org Admin. Exploitation is privilege-gated and interaction-dependent: the attacker needs an Editor account and the ability to host or point the panel at an external style config, and a different user must render the panel. Both Grafana OSS and Grafana Enterprise are affected across the 12.3.0, 12.4.x (through 12.4.10), 13.0.x (through 13.0.8), 13.1.x (through 13.1.5) and 13.2.x (through 13.2.1) release lines, per ENISA EUVD-2026-82430; no public exploit code was identified at time of analysis.
A race condition in the Linux kernel's batman-adv bridge loop avoidance (BLA) code can corrupt a mesh node's backbone CRC bookkeeping when another device on the same Layer-2 segment feeds CLAIM frames into the mesh. An unauthenticated attacker with Layer-2 adjacency to a node running batman-adv with BLA enabled can trigger the flaw only by winning a narrow, non-deterministic timing window between a concurrent claim-creation path and a backbone-change path for the same client MAC, leaving CRC state inconsistent for two backbone gateways at once. The impact is limited to corrupted loop-avoidance integrity/availability state (no host compromise, no memory-safety primitive, and no confidentiality impact); no public exploit has been identified at time of analysis, and BLA is not enabled by default on general-purpose systems.
A dangling-pointer condition in the Linux kernel's Broadcom V3D DRM driver (drm/v3d) leaves queue->active_job pointing at a freed job when v3d_fence_create() fails, so a later access through that stale pointer can crash the kernel (denial of service). Only systems running the V3D driver - primarily Raspberry Pi 4/5 boards - are affected, and the trigger requires local access to the DRM render/card device plus a rare failure of the dma_fence allocation inside v3d_fence_create(), which realistically only happens under memory exhaustion; for the BIN queue the dangling pointer must additionally race against v3d_overflow_mem_work(). Public patch commits and backports exist, and no public exploit code has been identified at time of analysis.
An out-of-bounds stack write exists in the Linux kernel's platform/chrome cros_ec_typec driver, where cros_typec_register_partner_pdos() copies USB-C Power Delivery objects from the ChromeOS Embedded Controller's TYPEC_STATUS response into the fixed seven-entry caps_desc.pdo array without validating the accompanying source_cap_count and sink_cap_count fields. If either 8-bit count exceeds PDO_MAX_OBJECTS (7), the memcpy overruns the stack buffer (a count of 255 overruns it by roughly 1 KB) and also reads past the equally narrow EC-side arrays. Affected systems are Chromebook-class hardware running the cros_ec_typec driver, and exploitation is gated on the EC firmware reporting a count above 7 - stock ChromeOS EC firmware caps these counts, so the flaw is only reachable with non-compliant, buggy, or attacker-controlled EC firmware; no public exploit identified at time of analysis, and the vendor score of 8.4 overstates real-world risk (our assessment is CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H).
Use-after-free in the Linux kernel HID core (hid_hw_stop()) can be triggered when a HID driver's probe enables input delivery via hid_device_io_start() and then fails a later initialization step, unwinding through hid_hw_stop(); the unwind frees the hidraw structure via hidraw_disconnect() while an in-flight report on another CPU may still dereference it through hidraw_report_event(). Roughly half of all hid_device_io_start() callers are exposed, with eight drivers named (corsair-psu, corsair-cpro, nzxt-kraken3, nzxt-smart2, gigabyte_waterforce, hid-logitech-dj, hid-nintendo, hid-mcp2221), while the seven callers that already pair the call with hid_device_io_stop() are unaffected. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); the vendor advisory rates this 8.8, but our independent assessment places real-world risk lower (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) because the attacker must have local device-attach capability and must win a narrow race during a probe failure.
Out-of-bounds read in the Linux kernel's AMDGPU power-management code (drm/amdgpu/pm/powerplay) allows a local attacker with high privileges to read past the end of voltage lookup tables, disclosing kernel memory contents or causing a denial-of-service crash when the driver initialises on affected hardware. Only systems using an AMD GCN-generation GPU that runs the legacy SMU7 powerplay path (Tonga, Fiji, Polaris and similar) are affected, and the malformed vddInd/vddcInd values must originate from VBIOS-parsed firmware tables, so triggering the bug requires supplying or flashing crafted GPU firmware rather than any ordinary runtime input. The published CVSS score is 7.1, but this analysis assesses the realistic risk as modest: exploitation is local-only, requires high privileges and attacker-controlled firmware, and no public exploit code has been identified at time of analysis; vendor patches are available in the stable kernel releases listed in the advisory (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1).
Out-of-bounds reads in the Linux kernel's AMDGPU PowerPlay driver for Vega10 GPUs allow kernel memory to be read past the end of the vddc, vddci and vddmem voltage lookup arrays, typically causing a kernel crash and potentially disclosing adjacent memory contents at nine separate lookup sites. Exploitation is limited to local, privileged actors or to systems whose VBIOS/firmware PowerPlay tables have been corrupted, since the offending vddInd, vddciInd and mvddInd values are derived from VBIOS-parsed tables rather than from ordinary unprivileged user input; the vendor rates the issue CVSS 7.3 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H), while our independent assessment scores it lower (AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:H) because reachability requires control over or corruption of the GPU firmware tables plus specific Vega10 hardware. Vendor-released patches are available in the 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.x stable branches, and no public exploit code has been identified at time of analysis; the EPSS/KEV feeds show no confirmed active exploitation. The system fully recovers only after the out-of-range index is rejected with -EINVAL, which is the fix the upstream commits introduce.
A race condition in the Linux kernel's xilinx_dma driver can cause the AXIDMA or MCDMA interrupt handler to mark a channel idle and start a new transfer while the channel's active descriptor list still holds unprocessed descriptors, leading to spurious transfer attempts, descriptor corruption, and missed completions. It affects kernels built and running on Xilinx Zynq, ZynqMP, or Versal FPGA SoCs (or equivalent IP) with these DMA engines in use, and the vendor CVSS of 7.8 with PR:L indicates a local user with basic privileges is required; no public exploit code exists and there is no confirmed active exploitation at time of analysis. Our independent assessment rates it lower than the vendor (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) because the condition is a timing-dependent completion-path race rather than attacker-controlled input, and the vendor's AC:L plus full C:H/I:H triad is not supported by the technical description.
Memory overread in the Linux kernel's platform/chrome cros_ec sensorhub ring handler can copy past the end of a host-command response buffer, disclosing adjacent kernel memory and, if the bad copy faults, panicking the kernel. It affects the cros_ec_sensorhub driver used by ChromeOS devices with EC-attached motion sensors, and is only reachable when the Embedded Controller firmware reports a max_response_packet_size small enough that cros_ec_cmd_xfer() clamps the FIFO-info response below the length the ring handler computes from the sensor count. Upstream fixes are published for numerous stable branches (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and mainline 7.3-rc1); there is no public exploit identified at time of analysis and the CVE is not in CISA KEV. The vendor-issued CVSS of 7.7 (AV:L/AC:L/PR:N/UI:N/C:H/I:N/A:H) is judged to overstate real-world risk - the independent assessment rates it AV:L/AC:H/PR:H/UI:N/C:L/I:N/A:H, requiring high privilege level and a malfunctioning or tampered EC rather than a userspace-controllable input.
Use-after-free in the Intel irdma RDMA driver in the Linux kernel allows a local user who can issue RDMA verbs against an irdma device to deregister a memory region that is still backing a live queue-pair, completion-queue or shared-receive-queue ring, because the driver never takes an additional reference on those userspace ring MRs before associating them with the ring objects. Affected systems run a kernel with the irdma driver (present since roughly 5.14) up to the fixed releases 6.18.52, 7.2.6 and 7.3-rc1, and must expose an Intel E800/X722-class RDMA device node to the untrusted local user. Exploitation requires local access with RDMA verbs privileges (CVSS vector PR:L, AV:L), is not reachable over the network, and no public exploit code has been identified at time of analysis; the issue is not listed in CISA KEV.
Unreleased RDMA response resources leak kernel memory in the Linux kernel's NVMe-over-Fabrics RDMA target (nvmet-rdma) when a queue pair is torn down while I/O responses are still in flight, so their send completions never fire and the associated rdma_rw contexts and request SGLs are never freed. The issue affects kernels since the RDMA target transport appeared (reported as far back as Linux 4.8) and is triggered by removing the target, resetting the RDMA connection, or otherwise dismantling a queue with outstanding responses - an operation reachable by a local actor holding low privileges on the target host (CVSS:3.1/AV:L/AC:H/PR:L/UI:N). Impact is availability-only and accumulates slowly, since each teardown leaks only small allocations and many repeated cycles are needed to exhaust memory; no public exploit code or active exploitation has been identified at time of analysis, and vendor patch releases are available.
A code-generation defect in the Linux kernel's s390 BPF JIT compiler causes 32-bit CPU-number loads to leave stale data in the upper 32 bits of the 64-bit BPF_REG_0 register, so eBPF programs running on IBM Z (s390x) hosts can receive incorrect, non-zero-extended values. The flaw is only reachable by a local actor who can load and execute an eBPF program (CAP_BPF, or CAP_SYS_ADMIN on older kernels) on an s390x system and whose program reads the current CPU number; it is not reachable remotely or on other architectures. The vendor-assigned CVSS 3.1 base score is 7.8, but our independent assessment rates the practical impact considerably lower (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), and no public exploit was identified at time of analysis.
Memory-ordering race in the Linux kernel BPF verifier (bpf_get_btf_vmlinux) lets a local attacker holding CAP_BPF or CAP_SYS_ADMIN potentially consume a partially initialized vmlinux BTF object, because the store that publishes the parsed pointer and the lockless fast-path load that reads it are not ordered. Exploitation is constrained to weakly ordered CPUs (arm64, PowerPC, RISC-V) and to the one-time lazy first-parse window, where a concurrent second caller must win a narrow race before btf_parse_vmlinux()'s stores to the struct and to external globals such as bpf_ctx_convert.t become visible; on strongly ordered x86 the missing barrier is effectively benign. The vendor scores this 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), but our independent assessment rates real-world risk LOW (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) given the privilege requirement, architecture dependence and first-parse-only timing window, and no public exploit has been identified at time of analysis.
A race-condition-driven use-after-free in the Linux kernel BPF subsystem allows a local user able to load and run BPF programs to crash or potentially corrupt kernel memory by racing a foreign task's mm_struct teardown against the bpf_find_vma() helper. The bug affects kernels from the 5.17 era onward that expose bpf_find_vma() on the foreign-task path, and it is reachable only when the attacker can reference a target task that concurrently executes exit_mm(); the current-task path is safe because task->mm is stable there. There is no public exploit identified at time of analysis, the flaw is not listed in CISA KEV, and the vendor has published upstream and stable patches; the vendor CVSS vector (7.8) overstates real-world risk relative to the independently assessed local, high-complexity race (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H), which reflects the tight timing window and the BPF load privileges required.
A BPF verifier scalar-id tracking flaw in the Linux kernel allows a local attacker who can load eBPF programs to make the verifier believe a sign-extended stack-filled register holds a different value than it does at runtime, which can be converted into an out-of-bounds memory access. Exploitation is local and requires the privilege to load BPF programs - CAP_BPF or CAP_SYS_ADMIN, or a system where the unprivileged BPF sysctl has been left enabled (disabled by default on most modern distributions) - and the kernel must be new enough to support BPF_MEMSX sign-extending narrowing loads (roughly 6.6 / cpu=v4 and later). The verifier miscalculation is deterministic once the precise instruction pattern is built, so attack complexity is low, but no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); EPSS-style urgency therefore stems from the high confidentiality, integrity and availability impact (CVSS 7.8) rather than observed exploitation.
Local attackers with access to a Linux device configured in USB gadget/peripheral mode can trigger undefined behavior in the FunctionFS (f_fs) DMABUF transfer error paths, causing a kernel crash or other availability impact. Affected kernels are those with f_fs DMABUF support (present since Linux 6.9) where ffs_dmabuf_transfer() handles endpoint-disabled (ESHUTDOWN) or request-allocation failure (ENOMEM) by calling dma_fence_put() on an uninitialized fence; an attacker must have local privileges over the gadget interface and deliberately induce one of these error conditions, making exploitation high-complexity and not remotely reachable. No public exploit has been identified at time of analysis, and the flaw is not confirmed actively exploited (CISA KEV); vendor patches are available in Linux 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1.
Linux kernel 6.15 and later (through 6.18.51 and 7.x before 7.2.6) let a locally loaded BPF program write through a borrowed, read-only cpumask pointer, because bpf_cpumask_populate() types its destination as 'struct cpumask *' instead of the expected program-owned 'struct bpf_cpumask *'. An actor able to load and run BPF programs - requiring CAP_BPF or effectively CAP_SYS_ADMIN plus the sched_ext (scx) cpumask kfuncs - can therefore have the verifier accept a const cpumask returned by a read-only query helper such as scx_bpf_get_online_cpumask() as a writable destination, corrupting memory the program does not own and degrading integrity and availability of the kernel. The vector is strictly local (AV:L, PR:L, UI:N) with no confidentiality impact assessed, and no public exploit code has been identified at time of analysis; vendor-released patches are available in 6.18.52, 7.2.6 and 7.3-rc1.
Linux kernel BPF trampoline handling fails to mark tracing_multi trampolines as ftrace managed, so releasing a tracing_multi (fentry-multi) link after an fentry link has also been attached produces a kernel WARNING in bpf_trampoline_multi_detach and leaves the trampoline link improperly managed. Only systems where a user holds BPF privileges (CAP_BPF or CAP_SYS_ADMIN) and uses the newer tracing_multi/fentry-multi link types are affected, with local access required (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L); there is no remote reachability and no unprivileged path on hardened configurations. The observable impact is a warning and a leaked or mismanaged link rather than attacker-controlled memory corruption, and no public exploit code was identified at time of analysis.
A race condition in the Linux kernel's RDMA/rxe (Soft-RoCE) responder state machine lets a single received packet be re-executed and re-completed once per posted receive WQE when a queue pair transitions to the error state mid-completion, producing hundreds of duplicate IB_WC_SUCCESS completions that are indistinguishable from genuine receives, then a kernel NULL pointer dereference in copy_data()/send_data_in() once the receive queue is exhausted. Kernels from 6.4 (starting with commit 49dc9c1f0c7e) up to the fix are affected; Soft-RoCE is not enabled by default in most deployments, and our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, well below the vendor's 8.2 (AV:N/AC:L/PR:N/UI:N), because triggering requires an established Reliable Connection queue pair, an active receive queue, and a narrow disconnect/receive timing window rather than a single request. There is no CISA KEV listing and no public exploit code identified at time of analysis.
A corrupted HFS+ filesystem image can cause a heap out-of-bounds write in the Linux kernel's hfsplus driver when the catalog thread record located by CNID in hfsplus_delete_cat() is not validated before its nodeName.length is used to rebuild a catalog delete key. The vulnerable path is reached with str == NULL, which happens when the last open reference to an unlinked HFS+ hardlink backing inode is closed, and is limited to Linux systems that have the hfsplus module (CONFIG_HFSPLUS_FS) loaded and are willing to mount an attacker-supplied or corrupted HFS+ volume; mounting untrusted images normally requires CAP_SYS_ADMIN or an unprivileged automount/udisks configuration. Local access and a crafted image are both prerequisites, and no public exploit code was identified at time of analysis; note that HFS+ (HFS Plus) is distinct from the newer Apple File System (APFS). The vendor-assigned CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is judged to overstate real-world risk; exploitation requires mounting a malicious image and then triggering unlinked-hardlink cleanup, so no public exploit code was identified at time of analysis and the flaw is not exploitable against default configurations that never mount untrusted HFS+ media.
A heap out-of-bounds write in the Linux kernel's CXL Features subsystem (cxlctl_get_feature) lets a local user who can reach the FWCTL_RPC interface corrupt kernel heap memory by supplying a small fwctl_rpc.out_len alongside a large cxl_mbox_get_feat_in.count, causing the CXL device to write past the end of a kvzalloc()'d buffer. Only systems running kernel 6.15 or later with the CXL Features subsystem built in and a Features-capable CXL device bound are affected, and the attacker must hold a handle to the fwctl character device (/dev/fwctl) and the privileges required to use it (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H, 7.8). This is a genuinely attacker-controlled out-of-bounds write rather than a probe or error-path crash, but it is not remotely reachable, no public exploit has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV).
Incorrect kernel virtual address computation in the Linux kernel DAX/fsdev direct_access path (__fsdev_dax_direct_access) causes the returned kaddr to be wrong for device-dax devices configured as multi-range with physical gaps between ranges, since the code adds a device-linear byte offset to virt_addr (the __va of ranges[0]) instead of translating the physical address directly. This is a local-only correctness/memory-safety bug: the vendor-assigned CVSS is 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), while independent assessment rates it CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H because the flaw is only reachable on a non-default, hardware/topology-specific multi-range layout and the dominant effect is memory corruption or kernel instability rather than clean confidentiality loss. Exploitation requires a local principal with permission to perform DAX direct_access on such a device; no public exploit code was identified at time of analysis and there is no confirmed active exploitation.
A double-free in the Linux kernel's Intel IPU6 media driver (media: ipu6) occurs when the isys/psys auxiliary-device initialization fails and its error-unwinding path frees the platform data pointer a second time. Kernels built with the ipu6 bridge - introduced in Linux 6.10 and used on systems with Intel IPU6 / MIPI camera hardware - are affected, and reaching the flaw requires local, high-privileged access plus a specific driver-init failure (MMU initialization or auxiliary_device_add() failure) rather than an ordinary attacker-controlled syscall. No public exploit code has been identified at time of analysis; the assessed impact is limited to a low-availability fault (local, high privileges, high attack complexity) rather than the 7.8 score carried in the raw NVD feed.
A buffer overflow in the Linux kernel's iwlwifi MEI coexistence code (iwlmei) lets a party able to inject SAP messages over the MEI bus trigger an out-of-bounds memory write by declaring a message length larger than the driver's local buffer, which the code reads without validating. Affected systems are limited to kernels built with CONFIG_IWLMEI on Intel hardware where CSME/AMT coexists with the Wi-Fi device - a non-default, enterprise-oriented configuration; standard iwlwifi deployments are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but the flaw is remotely reachable only from a compromised CSME/ME firmware or equivalent MEI-side attacker, so the practical prerequisites are substantial even though the vendor score of 8.4 (AV:L/AC:L/PR:N) overstates ease of reach. Vendor-released fixes are available in 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
Use-after-free in the Linux kernel's Userspace I/O (uio) subsystem can expose freed kernel memory and crash the kernel when a local process opens /dev/uioX at the exact moment a UIO device registration fails at a step after device_add() has already made the node visible to userspace. The failing path unwinds the device but leaves idev->info pointing at the driver's caller-owned struct uio_info, so an already-open file descriptor can later follow that dangling pointer into memory the driver has freed after seeing registration fail. Exploitation requires local access with low privileges (CVSS PR:L per the assessed vector), a difficult-to-win kernel race (AC:H), and a UIO driver that genuinely hits a post-device_add() setup failure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the independent assessment rates real-world risk as low-to-moderate despite the vendor-associated 7.0 CVSS score.
An out-of-bounds read in the Linux kernel's software_node_get_reference_args() helper is caused by a bounds check that fails to reject an index value of -1 (UINT_MAX), allowing the property reference array to be read past its end. Only local users with some existing privileges (CVSS PR:L) who can reach this niche fwnode/software-node code path can trigger it, and exploitation is rated high complexity because a specific caller-supplied index is required; the practical outcome is primarily a kernel crash or denial of service, with at most limited information disclosure. No public exploit code has been identified at time of analysis, the flaw is not confirmed as actively exploited (not in CISA KEV), and vendor patches are available in the listed stable kernel releases.
A memory-corruption bug in the Linux kernel's BPF arena allocator allows a local attacker who can load BPF programs (effectively CAP_BPF on kernels from about 6.9 onward) to corrupt the arena free tree and cause a subsequent allocation to hand back an address below the arena mapping. The flaw is reached by calling bpf_arena_free_pages() with a scalar arena address whose value falls below the low 32 bits of the arena base; the masked reconstruction then produces full_uaddr below user_vm_start, and the existing upper-end clipping converts this into an out-of-range free-tree offset. Privileges are required (CVSS PR:L, AV:L), there is no public exploit code identified at time of analysis, and the issue is not confirmed as actively exploited (not in CISA KEV); the vendor rates it 7.8 while our independent assessment rates it lower (C:L/I:L/A:H) because exposure is confined to callers already trusted to load BPF programs.
A use-after-free in the Linux kernel's dw-edma (DesignWare eDMA) DMA engine driver lets a local user who can submit and then synchronously terminate DMA transfers trigger a late virt-dma completion callback that dereferences client state already freed, risking kernel memory corruption or a denial of service. Kernels built with the dw-edma driver (present since Linux 5.3) on platforms exposing the corresponding PCIe/SoC eDMA controller and running a DMA client that submits transfers are affected; fixes are available in stable releases 6.6.157, 6.12.110, 6.18.52, 7.2.6 and in mainline 7.3-rc1. The vendor-listed CVSS of 8.8 (AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H) substantially overstates the risk: exploitation requires local access and winning a narrow race in which a deferred STOP must reach the interrupt handler after the client's state has been freed, and no public exploit has been identified at time of analysis.
A memory-safety flaw in the Linux kernel's Amlogic Meson ASoC sound-card driver (meson_card_reallocate_links()) allows a local user on affected Meson hardware to trigger a use-after-free and double free of card->dai_link, but only when the first krealloc() succeeds and relocates the array while the second krealloc() then fails under genuine kernel memory exhaustion. Because the trigger is an allocator-conditioned failure on the driver's probe/error path with no attacker-controlled data path and no remote reachability, our independent assessment rates the real-world impact as limited to availability (assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), notably lower than the 7.4 that reflects the raw memory-safety class. There is no public exploit code and no confirmed active exploitation at time of analysis; vendor-released fixes are available in stable branches 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110 and 6.18.52 (plus 7.3-rc1).
In the Linux kernel's Intel Omni-Path hfi1 RDMA driver, a local user able to submit SDMA/verbs transmit work requests can reach an error path where sdma_txinit_ahg() fails to initialize the TX request but set_txreq_header_ahg() ignores that failure and reports success, so the caller continues operating on an uninitialized txreq and the kernel can corrupt memory and crash, producing a denial of service. Exposure is limited to hosts with an Intel Omni-Path fabric adapter, the hfi1 driver loaded and in active use, and a user with the privileges needed to issue RDMA work requests (PR:L) - and the bug only fires when an internal SDMA initialization failure actually occurs, which is not attacker-supplied input and is hard to force on demand. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the vendor scores this 7.8, while our independent assessment rates it as an availability-only impact (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) and considers the vendor severity overstated for this specific defect.
An out-of-bounds read in the Linux kernel's RDMA/rxe (Soft-RoCE) driver lets a local unprivileged user who can post work queue entries directly into a user queue pair's submission ring drive copy_data() to index past the per-WQE scatter/gather array using an attacker-controlled cur_sge value or an oversized num_sge, producing a vmalloc out-of-bounds read that can crash the kernel. Exploitation is strictly local and requires the rdma_rxe module to be loaded with an rxe device configured plus the ability to open the InfiniBand uverbs interface and create a user-space QP that posts a payload-bearing WQE - a niche, non-default configuration; kernel-created QPs already enforce the num_sge bound. There is no public exploit code or confirmed active exploitation identified at time of analysis, and the issue was reported and fixed upstream, with patched stable releases including 6.1.188, 6.6.157, 6.12.110 and 6.18.52, so this is best treated as a low-priority local denial-of-service issue with limited confidentiality exposure.
Out-of-bounds memory reads in the Linux kernel ACPI processor IOAPIC hotplug lookup affect systems with x86 IOAPIC/CPU hotplug support where MADT and _MAT records are parsed. A local attacker with privileges (PR:L) and the ability to supply malformed ACPI firmware data-an IOAPIC entry whose declared generic-header length exceeds the available record range or that lacks the full fixed IOAPIC body-can trigger kernel memory over-read (C:L) and a likely crash or system unavailability (A:H); integrity impact is absent. This is a moderate-priority defensive kernel hardening fix rather than an urgent remotely exploitable flaw: exploitation is local only with high attack complexity and depends on firmware or privileged hotplug control, and no public exploit or active exploitation has been identified at time of analysis.
Kernel stack corruption in the Linux kernel on RISC-V builds compiled with CONFIG_CFI_CLANG is reachable through a BPF program that performs a tail call: prog->bpf_func already lands past the kcfi instruction during setup, so folding that instruction into the tailcall jump offset again overshoots by 4 bytes and skips the stack-pointer adjustment, leaving a corrupted kernel stack. Triggering it requires a local actor able to load and run the offending BPF program (CVSS PR:L, typically CAP_BPF/CAP_SYS_ADMIN), a RISC-V kernel, and CONFIG_CFI_CLANG; non-RISC-V kernels and builds without CFI_CLANG do not execute the affected codepath. Independent assessment rates this a local, low-severity-in-practice reliability/corruption bug whose practical impact is primarily availability (crash/disrupted stack), with limited integrity impact, and no public exploit identified at time of analysis.
A use-after-free race in the Linux kernel RDMA core lets a local, low-privileged user who can create and destroy completion queues trigger memory corruption during CQ teardown in ib_destroy_cq_user(), because vendor-specific CQ resources may be freed before the CQ is removed from the restrack registry. The bug is reachable only on hosts with the InfiniBand/RDMA stack loaded and an RDMA device exposing the uverbs/netlink restrack interfaces, and only through a narrow timing window, so per independent assessment it is a low-priority local denial-of-service rather than the 7.8 vendor score suggests (assessed vector AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis; vendor-released fixes exist in stable releases including 6.1.188, 6.6.157, 6.12.110, 6.18.52 and 7.2.6.
Use-after-free in the Linux kernel's RDMA core (ib_destroy_srq_user()) allows a local attacker who can allocate shared receive queues to race SRQ teardown against a concurrent netlink/restrack lookup, potentially crashing or destabilizing an RDMA-capable host. The assessed vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) indicates an authenticated local actor with low privileges on a machine exposing an RDMA stack (InfiniBand, RoCE, or iWARP), with impact limited to availability - the high-complexity timing race makes reliable exploitation unlikely and no memory-corruption outcome is confirmed. No public exploit code and no confirmed active exploitation were identified at time of analysis; RDMA hardware and drivers are uncommon outside datacenter and HPC environments, which sharply narrows the exposed population.
A use-after-free race in the Linux kernel RDMA core (ib_free_cq()) can crash or destabilize hosts that use InfiniBand, RoCE, or iWARP fabrics. An authenticated local user who can query completion queues through the RDMA netlink resource-tracking (restrack) interface can win a narrow timing window against a concurrent CQ teardown, because rdma_restrack_del() is executed only after vendor-specific CQ resources have already been freed, leaving the CQ briefly reachable via restrack. The assessed impact is denial of service only (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) given the non-deterministic race and the local-only reach on RDMA-configured systems; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
A use-after-free race in the Linux kernel's RDMA core (ib_core) lets a local user who can query Protection Domains over the RDMA netlink/restrack interface dereference a PD object after its vendor-specific resources have already been freed, during the narrow window at the end of ib_dealloc_pd_user(). Only hosts with the RDMA subsystem active (InfiniBand, RoCE, or iWARP drivers loaded) and reachable by the attacker's context are affected, and winning the timing window is non-deterministic, so the realistic outcome is a kernel crash or denial of service rather than memory corruption with a clear privilege-escalation path. Per the CVSS vector the attacker must already hold local credentials (PR:L, AV:L); no public exploit code has been identified at time of analysis, and the bug should be treated as a modest-priority local reliability/memory-safety issue despite the vendor's 7.8 score.
Error-path resource cleanup in the Linux kernel's Intel INT3400 (DPTF) thermal driver leaves per-ODVP sysfs files and their backing storage allocated when probe fails after evaluate_odvp() has already run - for example when thermal_tripless_zone_device_register() or a later probe resource registration fails. The affected code is present only on Intel platforms that expose the INT3400 ACPI device and is reached solely through ACPI firmware or hardware-driven probe failures, not attacker-supplied input, so impact is bounded to leaked sysfs objects and kernel storage with no confidentiality or integrity effect. The assessed vector (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L) reflects a low-severity local resource leak rather than a memory-safety flaw; exploitation requires high privileges on the local system, no public exploit identified at time of analysis, and vendor-released stable patches are available for the maintained branches.
A double-free in the Linux kernel's IPsec/xfrm device direct-output path (xfrm_dev_direct_output()) can crash the affected host when a netfilter hook drops an outgoing packet whose skb ownership has already been transferred - the function frees the skb anyway, corrupting memory and invalidating any other owner. Affected kernels are the 6.6.x line from 6.6.85 up to (but not including) 6.6.157, 6.12.x from 6.12.21 to before 6.12.110, and 6.13.9 through 6.14, plus the corresponding mainline commit ranges; exploitation requires IPsec crypto/packet offload configured on the egress device together with a netfilter/nftables rule that drops on that path, so real-world reach is narrow and the assessed impact is a local denial of service (host crash) rather than remote code execution or data exposure. Vendor-supplied CVSS is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), which is contradicted by the description, the code semantics, and the independent assessment (AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H). No public exploit code and no CISA KEV entry were identified - no public exploit identified at time of analysis - and vendor patches are available as 6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1 or later.
Failed object teardown in the Linux erdma (Alibaba Elastic RDMA Adapter) driver leaks queue buffers, MTTs, doorbells, and the STAG, QPN, CQN and AHN identifiers, because erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr() and erdma_destroy_ah() return early when erdma_post_cmd_wait() fails instead of completing software-side release. The leak path is only reachable when a device destroy command times out, an event that clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue; the RDMA core then keeps the object after the failed destructor, and forced uverbs cleanup nulls the pointers so the resources become unreachable. This is a hardware/firmware fault condition rather than an attacker-injectable bug, limiting practical risk: local access to a host with the erdma driver loaded is required (CVSS PR:L, AV:L, AC:H), no public exploit code was identified at time of analysis, and the vendor score of 7.0 (C:H/I:H/A:H) substantially overstates impact, which our assessment confines to a local resource/availability effect (A:L).
Signed integer overflow in the Linux kernel's mlx5 RDMA driver (RDMA/mlx5) lets a local user who already holds RDMA access to a Mellanox/NVIDIA ConnectX device create a user QP with a buffer smaller than the hardware will write into, producing a local out-of-bounds write and memory corruption (CVSS 3.1 base 7.8; our independent assessment scores it AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H). Only hosts exposing an mlx5 device through the verbs uAPI (for example /dev/infiniband/uverbs*) to a user with RDMA permissions are exposed; the vector is local and not network-reachable. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but vendor patches are available for all supported stable branches.
A race condition in the Linux kernel's NVIDIA Tegra241 CMDQV (vCMDQ) SMMUv3 driver allows a local user with iommufd/VFIO privileges to trigger a NULL pointer dereference or use-after-free by destroying or creating a user VINTF at the same moment an error interrupt fires. The tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] without synchronization, and deinit_vintf() returns idx to the IDA before clearing the slot, so a reused index can be published and then clobbered with a stale NULL store. Per the independent assessment the realistic outcome is a host-kernel crash (denial of service) on Grace-class ARM64 hardware; the assessed vector is AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, reflecting the narrow timing window and the local privileged device access required. No public exploit code or confirmed active exploitation was identified at time of analysis.
The Linux kernel's tegra241-cmdqv IOMMU driver (the NVIDIA Grace vCMDQ virtualization acceleration path) mishandles vSID-to-Stream-ID mapping in tegra241_vintf_init_vsid() when the passed-through device's master exposes anything other than exactly one physical Stream ID: zero streams makes master->streams a ZERO_SIZE_PTR that is dereferenced out of bounds, while multiple streams results in only streams[0] being mapped, so guest vSID invalidations silently miss the remaining ATC/IOTLB entries. The consequence is a kernel-level out-of-bounds read (availability impact and limited information exposure) plus stale/incompletely invalidated IOMMU translation caches for a passthrough guest. Exploitation is not remote and not trivial: it requires local privilege sufficient to attach devices via iommufd/VFIO and configure a guest passthrough on tegra241 hardware with a non-standard device stream configuration, and no public exploit code or confirmed active exploitation exists at time of analysis. Note that the vendor CVSS of 8.8 materially overstates real-world risk relative to the independent assessment, which scores it AV:L/PR:L with scope unchanged and only low confidentiality/integrity impact.
A use-after-free in the Linux kernel's RDMA/rxe (Soft-RoCE) driver can be triggered by a local user who registers a memory region with On-Demand Paging enabled and then causes the ODP page-initialization to fail. When rxe_odp_init_pages() errors out, rxe_odp_mr_init_user() frees the user memory object but leaves the dangling pointer in mr->umem, so the subsequent MR cleanup path calls ib_umem_release() on freed memory and reads stale fields such as umem->is_dmabuf, which the kernel's own CVSS vector rates as 7.8 while our independent assessment scores it lower (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) because the failure path must be deliberately induced and the rxe driver plus ODP are rarely enabled in production. Exploitation is limited to local authenticated users with the privilege to issue ibv_reg_mr against an rxe device; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. Vendor patches are available in the stable kernel commits referenced by the advisory.
Malformed NILFS2 filesystem images can drive the Linux kernel's nilfs2 super-root block parser to read past the end of the super-root block, because the super-root inode's metadata size is trusted before nilfs_read_inode_common() validates it; the fix rejects inode sizes whose computed on-disk footprint exceeds the filesystem block size. Exploitation requires a local user to mount an attacker-supplied image (assessed vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H), so this is not reachable by a remote, unauthenticated network attacker, and the realistic outcome is a kernel crash or a bounded kernel-memory disclosure rather than code execution or reliable data theft. nilfs2 must be compiled in or loaded, which is uncommon outside specialized storage deployments, and no public exploit identified at time of analysis or confirmed actively exploited (CISA KEV) status was found in the available intelligence.
Out-of-bounds memory access in the Linux kernel's IB/isert iSER (iSCSI-over-RDMA) target allows a remote attacker who can reach an exposed iSER portal over an RDMA fabric to trigger reads beyond a fixed-size receive descriptor, and in the immediate-data path to hand an oversized scatterlist to the SCSI backend, potentially corrupting the backing store. Affected systems are Linux targets running the isert target driver with a configured LUN/backing store; the attacker must complete login and reach the full-feature phase, then negotiate a large TargetRecvDataSegmentLength and send a PDU whose BHS-declared data-segment length exceeds the bytes actually received. Vendor-released fixes exist for the stable branches (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.3-rc1), no public exploit code has been identified at time of analysis, and the vendor CVSS of 9.1 (AV:N) is assessed as overstated because exploitation requires RDMA-fabric adjacency rather than open-internet reachability.
A pre-authentication out-of-bounds read in the Linux kernel iSER (iSCSI Extensions for RDMA) target login path lets an attacker who can reach the RDMA fabric crash the host kernel, producing a denial of service. Only hosts exporting an LIO/target-core iSCSI target over the iSER RDMA transport (RoCE, iWARP, or InfiniBand) are affected; iSCSI targets served over plain TCP are explicitly not vulnerable because that path validates the declared login length with iscsi_target_check_login_request(), while isert never calls it. The vendor rates this 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H); our independent assessment keeps AV:N/AC:L/PR:N/UI:N but treats impact as availability-only (C:N/I:N/A:H), and no public exploit has been identified at time of analysis - though the upstream commit includes a deterministic soft-RoCE/KASAN reproducer.
Out-of-bounds reads in the Linux kernel's ath11k Qualcomm WiFi-6 driver allow a malformed WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT from device firmware to read past the bounds of a TLV payload. The flaw exists because no TLV policy entry enforces a minimum length for this event struct, and the firmware-supplied num_vdevs field is used directly as a loop bound over the vdev_ids array without validation; per the CVSS vector this is a local (AV:L) attack with no privileges required (PR:N), though the independent assessment rates it AC:H/C:L rather than the vendor's AC:L/C:H framing. Triggering it requires an affected Qualcomm ath11k adapter running a firmware image that emits an inconsistent num_vdevs value or event length - meaning a malicious or genuinely buggy firmware blob, not a remote network peer or unprivileged userspace API - and no public exploit has been identified at time of analysis. The kernel reads are limited to disclosure of adjacent memory (information leak) plus a potential denial-of-service if the out-of-bounds access faults.
Failure at the last stage of device probe in the Linux kernel's rtlwifi PCI driver leaves wireless registrations dangling because an incorrect goto label in rtl_pci_probe() skips rollback of rtl_init_rfkill(), ieee80211_register_hw() and rtl_debug_add_one(). The result is a resource leak on an already-registered mac80211 hardware object, a stale rfkill instance and a leftover debugfs entry, which can produce a use-after-free or denial-of-service condition on affected systems running Realtek rtlwifi PCI hardware. Independent assessment rates this as low impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) because the buggy path is local, requires an actual probe-time failure rather than attacker-supplied input, and needs a local user with low privileges plus Realtek rtlwifi PCI hardware present; no public exploit code and no confirmed active exploitation were identified at time of analysis.
In the Linux kernel's MHI host bus driver, an error path in mhi_register_controller() fails to unregister the controller device from sysfs when creation of the optional trigger_edl attribute fails, leaving a partially registered device behind in addition to dropping the device reference. The affected code is only reachable on systems where the MHI host bus driver is loaded and bound to supported Qualcomm modem/WWAN/PCIe-endpoint hardware, and the trigger requires an unlikely failure of sysfs_create_file() (for example an allocation failure under memory pressure) rather than attacker-controlled input. Although the vendor assigned a 7.0 High score, our independent assessment rates real-world risk as low: local access (AV:L), high complexity (AC:H), low privileges required (PR:L), and availability-only impact (C:N/I:N/A:L); no public exploit code has been identified at time of analysis and there is no evidence of active exploitation (not in CISA KEV).
Heap memory corruption in the Linux kernel ath12k WiFi7 driver stems from a stride mismatch in ath12k_wmi_mac_phy_caps_parse(): the mac_phy_caps buffer is sized from a firmware-clamped length, while the memcpy write and the subsequent reader both advance by full-struct pointer arithmetic, so firmware-supplied WMI mac_phy_caps TLVs shorter than sizeof(struct ath12k_wmi_mac_phy_caps_params) cause out-of-bounds heap writes on every slot after the first. Affected systems are those running the in-tree ath12k driver (introduced in Linux 6.3) with Qualcomm WiFi7 hardware such as WCN7850; the trigger is firmware/adapter-controlled data rather than network traffic, which is why the independent assessment rates the issue AV:L/PR:H with High availability impact only, rather than the vendor's 8.4 vector with PR:N and full C/I/A. No public exploit code has been identified at time of analysis, there is no CISA KEV entry, and vendor-released fixes are available in stable releases 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
Heap out-of-bounds write in the Linux kernel ath11k WiFi driver (Qualcomm WiFi6 hardware) allows a malicious or malfunctioning firmware image to write kernel memory past the end of the allocated mac_phy_capabilities buffer while processing a WMI service-ready-ext message. The affected code has shipped since Linux 5.6 (commit 5b90fc760db5a969ed26d70f8e62c91915f012bd) and is fixed in stable versions 6.12.110 and 6.18.52, 7.2.6, and mainline 7.3-rc1; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV. The upstream CVSS 3.1 score is 8.4 with C:H/I:H/A:H, but our assessment rates it lower (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H) because exploitation requires control of the firmware/TLV stream the chip presents to the host, not ordinary network traffic or a normal unprivileged local API, and the fix was compile-tested only so real-world triggerability is not vendor-confirmed.
Local attackers holding CAP_BPF can trigger a use-after-free race in the Linux kernel's BPF link subsystem, where bpf_link_show_fdinfo() and bpf_link_get_info_by_fd() read link->prog without holding a lock while bpf_link_update() concurrently swaps and frees that program, yielding a crash (availability loss) or disclosure of freed kernel memory. Kernels from v5.7 up to the fixed backport releases (6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1) are affected; exploitation is gated by a narrow, probabilistic timing window and requires local access plus the ability to create, read, and update a BPF link. There is no remote vector, no confirmed active exploitation (not in CISA KEV), and no public exploit code identified at time of analysis.
A DMA-IOMMU error-handling defect in the Linux kernel allows a failed atomic DMA pool allocation to go undetected, so an invalid page can be handed to the IOMMU mapping path and trigger kernel memory faults resulting in denial of service. Affected builds are those exercising IOMMU-backed non-blocking, non-coherent DMA allocations (dma_alloc_from_pool()), and the bug only manifests when that pool allocation actually fails under memory pressure; exploitation requires local access sufficient to drive device DMA traffic (PR:L) plus a genuine pool-exhaustion condition that is not directly attacker-controlled (AC:H), giving an assessed availability-only impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code has been identified at time of analysis, and vendor-released fixes exist in the stable branches listed below.
A DMA-subsystem correctness flaw in the Linux kernel causes swiotlb dynamic pools to store an incorrect virtual address when a decrypted pool is allocated from the DMA atomic pool in atomic context, leading to failed chunk recognition on the pool free path. Only kernels built with CONFIG_DMA_DIRECT_REMAP (typical of confidential-computing/encrypted-DMA or certain ARM remapped-atomic-pool configurations) are affected, and the bug is locally reachable with no user-interaction or attacker-controlled input described; the independent assessment rates it as low severity (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) whose worst realistic outcome is atomic-pool resource leakage rather than code execution or data exposure. No public exploit code was identified at time of analysis, and vendor patches are available (Linux 6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1).
A timing-dependent race in the Linux kernel's misc/sgi-gru driver lets a local, low-privileged user who holds a GRU context trigger a lockless, reference-free walk of that process's page tables from interrupt context, so concurrent page-table modification or teardown can make the walker dereference stale page-table entries. Successful exploitation is expected to produce a kernel crash (availability impact) with limited potential information exposure, and requires a race that is timing-dependent rather than deterministically controllable. Exposure is narrow: the vulnerable code path is only reachable on systems with SGI GRU hardware (SGI UV/Altix x86-64 NUMA platforms) and the sgi-gru driver loaded; no public exploit has been identified at time of analysis, and vendor patches are available in 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1.
An out-of-bounds memory access in the Linux kernel's MediaTek mt76/mt7921e PCIe Wi-Fi driver can crash (kernel panic / denial of service) the local machine when a PCIe Advanced Error Reporting (AER) fault hangs the bus and register reads return 0xFFFFFFFF. The affected code is the mt7921e MAC-reset recovery path (mt7921_mac_reset_work -> mt7921e_mac_reset -> mt7921_wpdma_reset -> mt76_dma_rx_reset), which trusts the bogus DMA queue index and dereferences q->desc[]/q->entry[] out of range. Impact is limited to a local denial of service on systems that ship this driver and actually experience a hardware PCIe fault - this is a fault-tolerance defect, not an attacker-steerable memory-corruption issue - and no public exploit identified at time of analysis. Vendor-released patch: Linux 6.18.52, 7.2.6, and 7.3-rc1.
Linux kernel's mt76/mt7915 MediaTek Wi-Fi 6 driver can write an underflowed spatial-stream count (255) into firmware beamforming station records when an adjacent peer advertises a VHT/HE MCS map with all spatial-stream fields set to 0x3, corrupting the driver's view of that station's beamforming state. Exploitation requires radio adjacency (AV:A) and unauthenticated access per the CVSS vector (PR:N), with the attacker acting as an associating peer that reaches the mt7915_mcu_get_sta_nss beamforming station-record programming path; no public exploit code exists and no active exploitation is confirmed. The vendor rates this 7.1 with high availability impact, but independent assessment downgrades the severity because the effect is confined to firmware beamforming state with no memory-safety corruption, code execution, or confidentiality exposure.
A race condition in the Linux kernel's MediaTek mt76 WiFi driver can crash or hang affected systems, producing a denial of service by disrupting the RXDMAD_C buffer recycling path used by RRO (Receive Reorder Offload) data queues. The flaw affects kernels carrying the vulnerable mt76 code, notably the 6.18 series where the WiFi7/mt7996-class offload path is active, and it is exploitable by an unauthenticated attacker within adjacent wireless range (CVSS 3.1 AV:A/AC:H/PR:N/UI:N, with the independent assessment scoring availability-only impact, C:N/I:N/A:H). The trigger depends on winning a timing-sensitive race between the direct page-pool recycle and the buffer's owning NAPI, so it is not a deterministic single-packet trigger; there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Missing lock scope in the Linux kernel's mt76 mt7996 Wi-Fi 7 driver lets a reset/recovery path race with a channel change, allowing DMA ring descriptors and tokens to be corrupted. Only systems running a kernel from 6.4 onward on MediaTek MT7996/MT7992 (Wi-Fi 7) hardware are affected, and the trigger is a hardware/firmware L1 System Error Recovery event in mt7996_mac_reset_work() that must overlap an in-progress __mt76_set_channel() call - a narrow, non-attacker-controlled timing window rather than a packet-delivery path. Both the vendor vector's adjacent-network, unauthenticated profile (CVSS 8.8) and the 'Information Disclosure' tag overstate the practical issue: our independent assessment rates this as a concurrency/reliability defect (AV:A/AC:H, confidentiality and integrity not confirmed, availability High), and no public exploit has been identified at time of analysis. Vendor-released fixes are available in Linux 6.18.52, 7.2.6, and 7.3-rc1.
An out-of-bounds stack write exists in the x86 BPF trampoline code of the Linux kernel: btf_distill_func_proto() permits a function argument of up to 16 bytes, so a 128-bit scalar such as __int128 arrives with arg_size == 16, but the trampoline's register save-area sizing logic still assumes a single register for that argument. The result is an under-allocated save area that save_args() overruns into adjacent stack slots, corrupting the trampoline's own kernel stack frame. Exploitation requires local privilege sufficient to load and attach BPF programs (CAP_BPF or equivalent, matching the PR:L vector) on an x86 system, plus attaching an fentry/fexit-style trampoline to a kernel function whose prototype actually passes a 128-bit scalar - a rare signature. There is confirmed no public exploit identified at time of analysis; this is a local, privileged-attach memory-corruption issue rather than the 'Information Disclosure' tag some feeds applied to it, and vendor fixes are available in the 6.1, 6.12, 6.18 and 7.x stable lines.
Linux kernel Wi-Fi driver bug in the MediaTek mt76/mt7915 (mt7915e) TWT handling allows an adjacent, associated 802.11 peer to corrupt kernel memory by triggering a Target Wake Time agreement that the device MCU rejects, leaving a TWT flow linked on dev->twt_list while its flowid_mask is never set. The affected versions are Linux kernels carrying the mt7915 TWT support (introduced around 5.16) prior to the fixed releases 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1. Exploitation requires over-the-air adjacency and association plus the MCU-reject error path and a slot-reuse/memset race window, so it is not remotely reachable from the Internet; no public exploit code has been identified at time of analysis, and the vendor's CVSS 8.8 (C:H/I:H/A:H) overstates impact relative to the described list corruption and dangling-entry condition, which our assessment scores as availability-only (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H).
A use-after-free in the Linux kernel's mt76 mt7915 Wi-Fi driver (media/mediatek/mt7915) can crash the kernel, giving a local denial of service, when an ext-PHY-capable MediaTek MT7915 adapter registers its extension PHY successfully but then fails in a later initialization step (mt7915_init_debugfs() or mt7915_coredump_register()). The bug is in the error-unwind path: free_phy2 calls ieee80211_free_hw() on the ext PHY hardware while it is still registered with mac80211, because mt76_unregister_device() only tears down the main hw. Exploitation is tightly constrained - there is no remote vector and no user-controlled input; the failure window depends on internal allocation/registration faults (resource pressure or transient probe errors) during module load, and the assessed impact is kernel crash rather than attacker-directed code execution or data disclosure. No confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor's 7.0 High rating is not supported by this assessment, which rates the issue as low priority.
A teardown-ordering defect in the Linux kernel's cfg80211 wireless configuration layer allows a local user with wireless configuration privileges (CAP_NET_ADMIN) to desynchronize PMSR (peer measurement / FTM ranging) request state: cfg80211_stop_p2p_device() and cfg80211_stop_nan() tear down the mac80211 subinterface before aborting pending measurement requests, after which cfg80211 still frees the request while the lower driver can retain a stale pointer. The flaw affects kernels from roughly 5.0 through the fixed 6.18.52, 7.2.6, and 7.3-rc1 releases and requires a driver/hardware combination supporting PMSR plus P2P or NAN. The vendor's 7.8 score (C:H/I:H/A:H) reflects an assumed memory-corruption outcome, but our independent assessment scores it 7.8 → 6.2-equivalent as availability-only (AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H): a local reliability/denial-of-service bug rather than the high-impact information disclosure implied by the 'Information Disclosure' tag; no public exploit has been identified at time of analysis and there is no CISA KEV listing.
Malformed coreboot firmware tables can drive the Linux kernel's coreboot_table driver into mapping and parsing memory outside its declared platform resource, producing out-of-bounds reads that disclose kernel memory and crash the system on affected coreboot-based platforms. The flaw lives entirely in the boot/probe-time firmware parsing path (drivers/firmware/google/coreboot_table.c), so it is not reachable from an ordinary unprivileged local process: an attacker must be able to supply or corrupt the coreboot table itself, via firmware reflash, a malicious or compromised firmware image, or physical access, and the vulnerable code is absent altogether on systems that do not boot coreboot firmware. No public exploit code and no confirmed active exploitation were identified at time of analysis; vendor-released fixes are available in the stable kernels 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
A posted-write ordering bug in the Linux kernel DesignWare (dwc) PCIe endpoint driver can drop or misroute an MSI interrupt write when the iATU outbound window mapping the cached MSI target address is torn down and reprogrammed. Only systems running a Synopsys DesignWare PCIe controller in ENDPOINT mode on the MSI (not MSI-X) interrupt path are affected, and triggering it requires a narrow hardware/fabric race in which the Root Complex changes the cached MSI target address while a posted MSI write is still in flight - a legitimate reconfiguration event rather than attacker-supplied input. No public exploit code has been identified at time of analysis; the vendor CVSS of 8.2 is assessed as inflated, and the real-world impact is limited to reliability/ordering on embedded and SoC endpoint deployments, with no applicability to standard PCIe root-complex hosts such as servers, desktops, or laptops. The issue is resolved by reading back from the mapped MSI window before unmapping the iATU entry, mirroring the existing MSI-X flush fix.
A use-after-free race in the Linux kernel's HID subsystem allows a crafted or faulty HID device to crash the kernel: hid_device_io_start() permits report callbacks to run concurrently with driver probe, and if that probe then fails, __hid_device_probe() frees driver resources including the hidraw object and clears hdev->driver without first excluding an in-flight callback, so a report entering hidraw_report_event() ends up taking a freed list lock. Exploitation requires an attacker to supply or control a physical USB HID device (or be within Bluetooth HID range) whose driver probe fails while a report callback is executing, making this a local/adjacent availability issue - a kernel crash - rather than a remotely reachable or confidentiality-impacting one; no public exploit code and no confirmed active exploitation were identified at time of analysis. Upstream fixes have been released across the maintained stable branches.
A local use-after-free combined with a memory leak in the Linux kernel's blk-cgroup (block cgroup) subsystem allows a privileged local actor to crash or destabilize the kernel by racing IO-scheduler activation against concurrent block-cgroup deletion. Exploitation requires writing to /sys/block/<dev>/queue/scheduler (normally root/CAP_SYS_ADMIN) while simultaneously triggering blkcg teardown for a different blkg, and the corrupting path is only reachable through the ENOMEM rollback branch of blkcg_activate_policy(), so the attacker must also induce a policy-data allocation failure for one blkg during the window. Impact is limited to availability (kernel panic/UAF); there is no remote vector, no confidentiality or integrity loss, no public exploit identified at time of analysis, and no confirmed active exploitation.
A local privilege-holder can trigger a use-after-free race in the Linux kernel's block-cgroup (blk-cgroup) layer by switching a block device's IO scheduler at the same time a blkcg cgroup is being deleted; the race corrupts blkg reference counting and leads to an RCU callback being accelerated on a freed object, with the realistic outcome being a kernel panic or crash of the affected host rather than a controlled exploitation primitive. Affected are kernels in the vulnerable range spanning the 6.1, 6.2/6.3, 6.6, 6.12, 6.18 and 7.2/7.3 development trees (CPE cpe:2.3:a:linux:linux), and exploitation is constrained: the CVSS vector requires local access with high privileges (PR:H) and a hard-to-win timing window (AC:H), so repeated attempts may be necessary and reliability is inherently low. The vendor scores this 7.8 while the independent assessment rates it lower (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H, availability-only, roughly 4.1), there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, and vendor-released patches exist in the stable trees (for example 6.1.17, 6.2.4, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1).
Missing return-value validation in the Linux kernel's ublk userspace block driver lets a local actor who can drive a ublk block device pass an uninitialized struct iov_iter into ublk_copy_user_pages(), because import_ubuf() failures are silently ignored. Exploitation requires the ublk subsystem (CONFIG_BLK_DEV_UBLK) to be built or loaded and the attacker to control a userspace ublk server bound to a ublk device - by default this means holding CAP_SYS_ADMIN, or any user if the device was created with UBLK_F_UNPRIVILEGED_DEV. The practical outcome is a kernel crash from dereferencing garbage iov_iter fields (with a possibility of limited kernel memory disclosure), not reliable remote code execution; there is no network vector, and no public exploit identified at time of analysis, though the affected component is narrow enough that most general-purpose hosts are unaffected. The vendor-published CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) rates confidentiality and integrity impact high, while independent assessment is more conservative (6.5-level, AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H), treating availability loss from the crash as the dominant risk.
Unauthenticated remote connection flooding against the cockpit-tls front-end of Cockpit (the TLS terminator for the Cockpit web console, default TCP 9090) forces the service to spawn an unbounded number of detached threads, exhausting memory and file descriptors until the console degrades or becomes unavailable. The flaw, tracked as CWE-770 (allocation of resources without limits or throttling), carries a 7.5 CVSS score (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects Cockpit as shipped in Red Hat Enterprise Linux 7, 8, 9, and 10 as well as Red Hat OpenShift Dev Spaces; the CVSS vector confirms the attack needs no authentication or user interaction. Exploitation is bounded to availability of the management console rather than the underlying host services, CISA's SSVC assessment records Exploitation: none (automatable: yes, technical impact: partial), and no public exploit code was identified at time of analysis. Because the primitive is simply 'open many concurrent TCP connections,' it is highly automatable and becomes a practical risk anywhere port 9090 is reachable from an untrusted network.
Memory exhaustion in the adm-zip Node.js library before 0.6.1 allows remote, unauthenticated attackers to crash or severely degrade any service that reads entries from untrusted ZIP archives: a 105-byte crafted archive whose central directory declares an uncompressed size of ~1.77 GB forces the library to commit roughly 1.8 GB of resident memory before validation fails, which OOM-kills memory-constrained processes (containers, serverless, small VMs) and, with concurrency, can exhaust larger hosts. Publicly available exploit code exists - the vendor advisory includes a self-contained 105-byte base64 PoC (sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386) - and the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms a network-reachable availability-only impact with no privileges or user interaction required. There is no indication of confirmed active exploitation (not in CISA KEV), and applications that never parse attacker-controlled ZIPs are not exposed; the practical severity is governed by host memory limits rather than by any authentication or configuration bar.
Denial of service in libheif 1.23.1 and earlier: decoding a crafted HEIF/AVIF file whose derived-image reference graph (grid, iovl, or iden items) points many branches at a common base image causes the decoder to re-decode that base image repeatedly, exhausting CPU and, depending on tile handling, memory. The flaw is unauthenticated and remotely triggerable (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) against any service that automatically decodes attacker-supplied files - upload pipelines, thumbnailers, and transcoders are the highest-value targets - while desktop viewers require the user to open the file, effectively adding user interaction. Impact is availability-only (no code execution, disclosure, or modification), and no public exploit code was identified at time of analysis, though the weaponized input is a small, trivially constructed file. Vendor-released patch: 1.23.2.
Denial of service in libheif 1.19.0 through 1.23.1 allows unauthenticated remote attackers to exhaust process memory and terminate the application by supplying a crafted HEIF or AVIF file whose compressed mime metadata or unci image data is decompressed without an effective output bound. According to the CVSS vector (AV:N/AC:L/PR:N/UI:N) no privileges or interaction are required, so automated server-side image ingestion pipelines that parse untrusted HEIF/AVIF content are the most exposed; interactive desktop viewers still require a user to open the malicious file. Impact is availability-only (crash/OOM, no code execution or data disclosure), no public exploit code has been identified at time of analysis, and the issue is fixed in libheif 1.23.2.
Denial of service in uri-js through 4.4.1 lets remote, unauthenticated attackers stall a Node.js process indefinitely: the removeDotSegments routine enters an infinite loop when a path segment begins with a Unicode line separator (U+2028) or paragraph separator (U+2029), blocking the event loop until heap exhaustion. The package is an unmaintained, widely pulled-in dependency (commonly transitively, e.g. via ajv), so the risk is driven by prevalence: no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status. Exposure is limited to applications that actually route untrusted input into removeDotSegments directly, or into normalize()/resolve() with IRI handling enabled; code paths handling only trusted or internal URIs are not reachable by this bug.
Unauthenticated memory exhaustion in SGLang through 0.5.19 lets remote attackers force out-of-memory termination of the prefill process by submitting arbitrary bootstrap_room values to the decode engine's POST /generate endpoint. The flaw only manifests in a non-default deployment: prefill/decode disaggregation mode with the Mooncake KV transfer backend enabled, which is not the standard monolithic serving configuration, and the endpoint must be network-reachable. No public exploit code was identified at time of analysis, and the vulnerability is not confirmed actively exploited (CISA KEV); impact is confined to availability (CVSS 4.0 base 8.7; independent assessment scores the same issue 7.5 under CVSS 3.1), with no data exposure or code execution.
SMTP command injection in Netty's netty-codec-smtp allows unauthenticated remote attackers to inject arbitrary SMTP commands via CRLF sequences in the command-name field, affecting applications built on Netty such as Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7. This is an incomplete fix of CVE-2025-59419, requiring attacker-controlled input to reach the SMTP command name and a downstream SMTP server that acts on smuggled commands; no public exploit identified at time of analysis. Integrity impact is high, while confidentiality and availability are unaffected.
hickory-resolver releases before 0.26.2 fail to propagate a 'bogus' DNSSEC proof state out of the high-level Resolver::lookup() and Resolver::lookup_ip() APIs, so records that fail DNSSEC signature validation are handed back to the caller as successful, apparently validated answers. This is an integrity-only bypass affecting unauthenticated remote attackers (CVSS:4.0 8.7 / assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) who either control the authoritative zone answering the query or sit on the network path to inject forged records with invalid RRSIGs; applications that do not compile the crate's __dnssec feature are unaffected because they never expected validation in the first place. A vendor fix is available in 0.26.2 (commit 30720f4, PR 3871), and no public exploit code or confirmed active exploitation was observed at time of analysis. This is a genuine, high-priority integrity flaw despite the absence of exploitation telemetry.
Denial of service in Red Hat's Camel-based and Java middleware products (Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7): a STOMP frame that declares an oversized content-length is truncated from a 64-bit long to a 32-bit integer, yielding a wrapped/negative length that leaves the STOMP decoder unable to advance, so it loops indefinitely and burns CPU on the affected message-processing thread. The flaw is remotely reachable and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but exposure is strictly limited to deployments that actually enable a network-reachable STOMP listener - products without a configured STOMP endpoint are not attackable. No confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis.
Denial of service in rustls-webpki through 0.103.12 and in 0.104.0-alpha.1 through 0.104.0-alpha.6: a crafted certificate revocation list carrying an issuingDistributionPoint extension whose onlySomeReasons BIT STRING content is exactly [0x00] triggers an integer underflow in bit_string_flags() and panics the parsing process. Unauthenticated remote attackers can reach this only where an application has explicitly opted into CRL revocation checking by passing RevocationOptions to verify_for_usage() and parses CRL bytes from a source the attacker can influence (for example an attacker-supplied or MITM'd CRL distribution point); the default rustls configuration that omits RevocationOptions is unaffected. Publicly available exploit code exists - the GHSA-82j2-j2ch-gfr8 advisory ships a complete PoC CRL that reproduces the crash - but there is no confirmation of active exploitation, and the impact is purely availability (no confidentiality or integrity effect).
Privileged users inside a QEMU guest running on the Q35 machine type with the KVM accelerator can abuse the VAPIC setup hypercall (hw/i386/vapic.c) to break SMM isolation, because the code fails to verify that a writable RAM alias stays inside the option ROM window. By repositioning that alias over chipset-locked SMRAM, an attacker with root-equivalent guest access defeats D_LCK protection and injects code into System Management Mode memory, which QEMU scores as a scope-changing, total-impact compromise (CVSS 8.2). Exploitation is local to the guest with high privileges required (AV:L, PR:H, S:C), publicly available exploit code exists according to the CISA SSVC assessment, but there is no confirmed active exploitation and EPSS is low at 0.20% (10th percentile).
Unauthenticated remote attackers can cause a gradual denial of service in applications that use Netty's STOMP codec by sending a STOMP frame body without the terminating null byte; StompSubframeDecoder leaks a ByteBuf for each such frame, so sustained traffic exhausts JVM heap or direct memory. The issue carries CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning network-reachable, no authentication or user interaction, availability-only impact. Red Hat middleware products listed in CPE data are affected when STOMP-over-TCP/WebSocket is enabled; no public exploit code or confirmed active exploitation was identified at time of analysis, and a practical DoS requires repeated frames rather than a single packet.
Use-after-free code execution in PDFium, Chrome's bundled PDF rendering engine, allows a remote attacker who lures a victim into opening a crafted HTML page to run arbitrary code inside Chrome's renderer sandbox on any build prior to 153.0.8010.52. The bug is network-reachable and low-complexity with no authentication required, but it does require user interaction (the victim must navigate to the attacker-supplied page), and because the CVSS scope is unchanged (S:U) the compromise is contained within the renderer - full system takeover would require chaining a separate sandbox-escape flaw. Google has released a fixed build and there is no public exploit identified at time of analysis, though the CVSS 8.8 score and memory-corruption tag make timely patching advisable.
Heap buffer overflow in PDFium, the PDF rendering engine built into Google Chrome, allows a remote attacker to potentially execute arbitrary code inside the Chrome renderer sandbox on Windows systems running versions prior to 153.0.8010.52. Exploitation requires the victim to open an attacker-supplied crafted PDF (UI:R), so the attack is delivered via social engineering rather than direct network exploitation; no credentials are needed (PR:N) and default Chrome installations render PDFs without any special configuration. The vendor rates this High severity with a CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), and although a vendor patch is available, no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). Because code execution is confined to the renderer sandbox, full host compromise would additionally require a separate sandbox-escape vulnerability not covered by this advisory.
Type confusion in the V8 JavaScript engine of Google Chrome prior to 153.0.8010.52 allows remote, unauthenticated attackers to execute arbitrary code inside the renderer sandbox when a victim is socially engineered into loading a crafted HTML page (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Exploitation is not automatic: it requires user interaction, and because the resulting code execution is confined to the renderer sandbox, turning it into host-level compromise would require chaining a separate sandbox-escape vulnerability. There is no public exploit code identified at time of analysis and the flaw is not listed in CISA KEV, but a vendor patch (Chrome 153.0.8010.52) is available and this is a patch-now item for a ubiquitous product.
Local sandbox escape in Google Chrome on Windows (versions prior to 153.0.8010.52) lets an attacker who can already execute a program on the target host run arbitrary code outside the browser sandbox by abusing incorrect reference resolution in Chrome's Tracing component (CWE-706). The vendor rates it High with a CVSS of 8.1 (AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H), meaning exploitation is local-only, requires no user interaction, but is gated by high attack complexity - consistent with a race or timing-dependent condition that is not reliably repeatable. No public exploit code has been identified at time of analysis, and because a local foothold is a prerequisite, this is realistically a chained sandbox-escape stage rather than a standalone initial-access vulnerability.
Use-after-free in the Dawn (WebGPU) component of Google Chrome on Android before 153.0.8010.52 allows a remote, unauthenticated attacker to potentially execute arbitrary code outside the browser sandbox when a victim renders a crafted HTML page. Exploitation requires the user to load attacker-controlled content (CVSS 9.6, AV:N/AC:L/PR:N/UI:R), and Google rates the bug Chromium security severity Critical; the only affected configuration is Chrome on Android below the fixed 153.0.8010.52 build, and devices already updated are not exposed. There is no CISA KEV listing and no public exploit identified at time of analysis, so the practical risk is driven by the size of the unpatched Android install base rather than by observed attacks.
Use-after-free in Google Chrome's Extensions component allows a remote attacker to execute arbitrary code outside the browser sandbox on any desktop build prior to 153.0.8010.52, provided the victim loads a crafted, attacker-controlled extension. The flaw carries a 9.6 CVSS score (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), meaning no prior authentication to the target is needed, but the attacker must still persuade the user to install or load a malicious extension, which is the real-world limiting factor; the sandbox-scope change (S:C) reflects code execution escaping Chrome's renderer/extensions sandbox. A vendor patch shipping in 153.0.8010.52 is available, and no public exploit code or confirmed active exploitation has been identified at time of analysis. Because Chrome auto-updates aggressively, the exposed population shrinks quickly once the fixed build propagates.
Remote code execution outside the browser sandbox in Google Chrome on Android prior to 153.0.8010.52 is possible when a victim opens a crafted HTML page containing malicious WebGL content that triggers a stack-based buffer overflow. Unauthenticated remote attackers can achieve code execution in the context of the GPU/renderer process with high impact to confidentiality, integrity, and availability, though exploitation requires user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, 9.6, Chromium security severity Critical). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; Google has released a fixed build (153.0.8010.52) and the flaw is tracked as EUVD-2026-82476 and VulDB 407131.
Symlink-based archive extraction in Grafana OSS and Grafana Enterprise lets a malicious plugin archive write arbitrary files - including an executable backend binary - outside the plugin installation directory, and that binary then runs with the Grafana server process's privileges, yielding remote code execution. Exploitation is gated on a Grafana operator installing a plugin from an attacker-influenced archive (via the plugin catalog, grafana-cli, GF_INSTALL_PLUGINS, or preinstall configuration), which is the UI:R component of the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H vector; there is no unattended remote trigger against a running server. A key aggravating factor is that plugin archives are extracted before their signature is verified, so enforcing signed plugins does not mitigate this issue, and Grafana Enterprise carries the identical extraction code. No public exploit code has been identified at time of analysis, and the vulnerability is not in CISA KEV; independent assessment rates this a genuine high-priority issue rather than a high-CVSS-but-low-real-risk paper cut.
Stored cross-site scripting in Grafana's Geomap panel allows an authenticated user holding at least the Editor role to embed a malicious MapLibre base-layer style configuration whose attacker-controlled JavaScript executes in the browser session of any other user who views the panel, including an Org Admin, enabling privilege escalation to Org Admin. Exploitation is privilege-gated and interaction-dependent: the attacker needs an Editor account and the ability to host or point the panel at an external style config, and a different user must render the panel. Both Grafana OSS and Grafana Enterprise are affected across the 12.3.0, 12.4.x (through 12.4.10), 13.0.x (through 13.0.8), 13.1.x (through 13.1.5) and 13.2.x (through 13.2.1) release lines, per ENISA EUVD-2026-82430; no public exploit code was identified at time of analysis.
A race condition in the Linux kernel's batman-adv bridge loop avoidance (BLA) code can corrupt a mesh node's backbone CRC bookkeeping when another device on the same Layer-2 segment feeds CLAIM frames into the mesh. An unauthenticated attacker with Layer-2 adjacency to a node running batman-adv with BLA enabled can trigger the flaw only by winning a narrow, non-deterministic timing window between a concurrent claim-creation path and a backbone-change path for the same client MAC, leaving CRC state inconsistent for two backbone gateways at once. The impact is limited to corrupted loop-avoidance integrity/availability state (no host compromise, no memory-safety primitive, and no confidentiality impact); no public exploit has been identified at time of analysis, and BLA is not enabled by default on general-purpose systems.
A dangling-pointer condition in the Linux kernel's Broadcom V3D DRM driver (drm/v3d) leaves queue->active_job pointing at a freed job when v3d_fence_create() fails, so a later access through that stale pointer can crash the kernel (denial of service). Only systems running the V3D driver - primarily Raspberry Pi 4/5 boards - are affected, and the trigger requires local access to the DRM render/card device plus a rare failure of the dma_fence allocation inside v3d_fence_create(), which realistically only happens under memory exhaustion; for the BIN queue the dangling pointer must additionally race against v3d_overflow_mem_work(). Public patch commits and backports exist, and no public exploit code has been identified at time of analysis.
An out-of-bounds stack write exists in the Linux kernel's platform/chrome cros_ec_typec driver, where cros_typec_register_partner_pdos() copies USB-C Power Delivery objects from the ChromeOS Embedded Controller's TYPEC_STATUS response into the fixed seven-entry caps_desc.pdo array without validating the accompanying source_cap_count and sink_cap_count fields. If either 8-bit count exceeds PDO_MAX_OBJECTS (7), the memcpy overruns the stack buffer (a count of 255 overruns it by roughly 1 KB) and also reads past the equally narrow EC-side arrays. Affected systems are Chromebook-class hardware running the cros_ec_typec driver, and exploitation is gated on the EC firmware reporting a count above 7 - stock ChromeOS EC firmware caps these counts, so the flaw is only reachable with non-compliant, buggy, or attacker-controlled EC firmware; no public exploit identified at time of analysis, and the vendor score of 8.4 overstates real-world risk (our assessment is CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H).
Use-after-free in the Linux kernel HID core (hid_hw_stop()) can be triggered when a HID driver's probe enables input delivery via hid_device_io_start() and then fails a later initialization step, unwinding through hid_hw_stop(); the unwind frees the hidraw structure via hidraw_disconnect() while an in-flight report on another CPU may still dereference it through hidraw_report_event(). Roughly half of all hid_device_io_start() callers are exposed, with eight drivers named (corsair-psu, corsair-cpro, nzxt-kraken3, nzxt-smart2, gigabyte_waterforce, hid-logitech-dj, hid-nintendo, hid-mcp2221), while the seven callers that already pair the call with hid_device_io_stop() are unaffected. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); the vendor advisory rates this 8.8, but our independent assessment places real-world risk lower (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) because the attacker must have local device-attach capability and must win a narrow race during a probe failure.
Out-of-bounds read in the Linux kernel's AMDGPU power-management code (drm/amdgpu/pm/powerplay) allows a local attacker with high privileges to read past the end of voltage lookup tables, disclosing kernel memory contents or causing a denial-of-service crash when the driver initialises on affected hardware. Only systems using an AMD GCN-generation GPU that runs the legacy SMU7 powerplay path (Tonga, Fiji, Polaris and similar) are affected, and the malformed vddInd/vddcInd values must originate from VBIOS-parsed firmware tables, so triggering the bug requires supplying or flashing crafted GPU firmware rather than any ordinary runtime input. The published CVSS score is 7.1, but this analysis assesses the realistic risk as modest: exploitation is local-only, requires high privileges and attacker-controlled firmware, and no public exploit code has been identified at time of analysis; vendor patches are available in the stable kernel releases listed in the advisory (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1).
Out-of-bounds reads in the Linux kernel's AMDGPU PowerPlay driver for Vega10 GPUs allow kernel memory to be read past the end of the vddc, vddci and vddmem voltage lookup arrays, typically causing a kernel crash and potentially disclosing adjacent memory contents at nine separate lookup sites. Exploitation is limited to local, privileged actors or to systems whose VBIOS/firmware PowerPlay tables have been corrupted, since the offending vddInd, vddciInd and mvddInd values are derived from VBIOS-parsed tables rather than from ordinary unprivileged user input; the vendor rates the issue CVSS 7.3 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H), while our independent assessment scores it lower (AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:H) because reachability requires control over or corruption of the GPU firmware tables plus specific Vega10 hardware. Vendor-released patches are available in the 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.x stable branches, and no public exploit code has been identified at time of analysis; the EPSS/KEV feeds show no confirmed active exploitation. The system fully recovers only after the out-of-range index is rejected with -EINVAL, which is the fix the upstream commits introduce.
A race condition in the Linux kernel's xilinx_dma driver can cause the AXIDMA or MCDMA interrupt handler to mark a channel idle and start a new transfer while the channel's active descriptor list still holds unprocessed descriptors, leading to spurious transfer attempts, descriptor corruption, and missed completions. It affects kernels built and running on Xilinx Zynq, ZynqMP, or Versal FPGA SoCs (or equivalent IP) with these DMA engines in use, and the vendor CVSS of 7.8 with PR:L indicates a local user with basic privileges is required; no public exploit code exists and there is no confirmed active exploitation at time of analysis. Our independent assessment rates it lower than the vendor (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H) because the condition is a timing-dependent completion-path race rather than attacker-controlled input, and the vendor's AC:L plus full C:H/I:H triad is not supported by the technical description.
Memory overread in the Linux kernel's platform/chrome cros_ec sensorhub ring handler can copy past the end of a host-command response buffer, disclosing adjacent kernel memory and, if the bad copy faults, panicking the kernel. It affects the cros_ec_sensorhub driver used by ChromeOS devices with EC-attached motion sensors, and is only reachable when the Embedded Controller firmware reports a max_response_packet_size small enough that cros_ec_cmd_xfer() clamps the FIFO-info response below the length the ring handler computes from the sensor count. Upstream fixes are published for numerous stable branches (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and mainline 7.3-rc1); there is no public exploit identified at time of analysis and the CVE is not in CISA KEV. The vendor-issued CVSS of 7.7 (AV:L/AC:L/PR:N/UI:N/C:H/I:N/A:H) is judged to overstate real-world risk - the independent assessment rates it AV:L/AC:H/PR:H/UI:N/C:L/I:N/A:H, requiring high privilege level and a malfunctioning or tampered EC rather than a userspace-controllable input.
Use-after-free in the Intel irdma RDMA driver in the Linux kernel allows a local user who can issue RDMA verbs against an irdma device to deregister a memory region that is still backing a live queue-pair, completion-queue or shared-receive-queue ring, because the driver never takes an additional reference on those userspace ring MRs before associating them with the ring objects. Affected systems run a kernel with the irdma driver (present since roughly 5.14) up to the fixed releases 6.18.52, 7.2.6 and 7.3-rc1, and must expose an Intel E800/X722-class RDMA device node to the untrusted local user. Exploitation requires local access with RDMA verbs privileges (CVSS vector PR:L, AV:L), is not reachable over the network, and no public exploit code has been identified at time of analysis; the issue is not listed in CISA KEV.
Unreleased RDMA response resources leak kernel memory in the Linux kernel's NVMe-over-Fabrics RDMA target (nvmet-rdma) when a queue pair is torn down while I/O responses are still in flight, so their send completions never fire and the associated rdma_rw contexts and request SGLs are never freed. The issue affects kernels since the RDMA target transport appeared (reported as far back as Linux 4.8) and is triggered by removing the target, resetting the RDMA connection, or otherwise dismantling a queue with outstanding responses - an operation reachable by a local actor holding low privileges on the target host (CVSS:3.1/AV:L/AC:H/PR:L/UI:N). Impact is availability-only and accumulates slowly, since each teardown leaks only small allocations and many repeated cycles are needed to exhaust memory; no public exploit code or active exploitation has been identified at time of analysis, and vendor patch releases are available.
A code-generation defect in the Linux kernel's s390 BPF JIT compiler causes 32-bit CPU-number loads to leave stale data in the upper 32 bits of the 64-bit BPF_REG_0 register, so eBPF programs running on IBM Z (s390x) hosts can receive incorrect, non-zero-extended values. The flaw is only reachable by a local actor who can load and execute an eBPF program (CAP_BPF, or CAP_SYS_ADMIN on older kernels) on an s390x system and whose program reads the current CPU number; it is not reachable remotely or on other architectures. The vendor-assigned CVSS 3.1 base score is 7.8, but our independent assessment rates the practical impact considerably lower (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), and no public exploit was identified at time of analysis.
Memory-ordering race in the Linux kernel BPF verifier (bpf_get_btf_vmlinux) lets a local attacker holding CAP_BPF or CAP_SYS_ADMIN potentially consume a partially initialized vmlinux BTF object, because the store that publishes the parsed pointer and the lockless fast-path load that reads it are not ordered. Exploitation is constrained to weakly ordered CPUs (arm64, PowerPC, RISC-V) and to the one-time lazy first-parse window, where a concurrent second caller must win a narrow race before btf_parse_vmlinux()'s stores to the struct and to external globals such as bpf_ctx_convert.t become visible; on strongly ordered x86 the missing barrier is effectively benign. The vendor scores this 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), but our independent assessment rates real-world risk LOW (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) given the privilege requirement, architecture dependence and first-parse-only timing window, and no public exploit has been identified at time of analysis.
A race-condition-driven use-after-free in the Linux kernel BPF subsystem allows a local user able to load and run BPF programs to crash or potentially corrupt kernel memory by racing a foreign task's mm_struct teardown against the bpf_find_vma() helper. The bug affects kernels from the 5.17 era onward that expose bpf_find_vma() on the foreign-task path, and it is reachable only when the attacker can reference a target task that concurrently executes exit_mm(); the current-task path is safe because task->mm is stable there. There is no public exploit identified at time of analysis, the flaw is not listed in CISA KEV, and the vendor has published upstream and stable patches; the vendor CVSS vector (7.8) overstates real-world risk relative to the independently assessed local, high-complexity race (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H), which reflects the tight timing window and the BPF load privileges required.
A BPF verifier scalar-id tracking flaw in the Linux kernel allows a local attacker who can load eBPF programs to make the verifier believe a sign-extended stack-filled register holds a different value than it does at runtime, which can be converted into an out-of-bounds memory access. Exploitation is local and requires the privilege to load BPF programs - CAP_BPF or CAP_SYS_ADMIN, or a system where the unprivileged BPF sysctl has been left enabled (disabled by default on most modern distributions) - and the kernel must be new enough to support BPF_MEMSX sign-extending narrowing loads (roughly 6.6 / cpu=v4 and later). The verifier miscalculation is deterministic once the precise instruction pattern is built, so attack complexity is low, but no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); EPSS-style urgency therefore stems from the high confidentiality, integrity and availability impact (CVSS 7.8) rather than observed exploitation.
Local attackers with access to a Linux device configured in USB gadget/peripheral mode can trigger undefined behavior in the FunctionFS (f_fs) DMABUF transfer error paths, causing a kernel crash or other availability impact. Affected kernels are those with f_fs DMABUF support (present since Linux 6.9) where ffs_dmabuf_transfer() handles endpoint-disabled (ESHUTDOWN) or request-allocation failure (ENOMEM) by calling dma_fence_put() on an uninitialized fence; an attacker must have local privileges over the gadget interface and deliberately induce one of these error conditions, making exploitation high-complexity and not remotely reachable. No public exploit has been identified at time of analysis, and the flaw is not confirmed actively exploited (CISA KEV); vendor patches are available in Linux 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1.
Linux kernel 6.15 and later (through 6.18.51 and 7.x before 7.2.6) let a locally loaded BPF program write through a borrowed, read-only cpumask pointer, because bpf_cpumask_populate() types its destination as 'struct cpumask *' instead of the expected program-owned 'struct bpf_cpumask *'. An actor able to load and run BPF programs - requiring CAP_BPF or effectively CAP_SYS_ADMIN plus the sched_ext (scx) cpumask kfuncs - can therefore have the verifier accept a const cpumask returned by a read-only query helper such as scx_bpf_get_online_cpumask() as a writable destination, corrupting memory the program does not own and degrading integrity and availability of the kernel. The vector is strictly local (AV:L, PR:L, UI:N) with no confidentiality impact assessed, and no public exploit code has been identified at time of analysis; vendor-released patches are available in 6.18.52, 7.2.6 and 7.3-rc1.
Linux kernel BPF trampoline handling fails to mark tracing_multi trampolines as ftrace managed, so releasing a tracing_multi (fentry-multi) link after an fentry link has also been attached produces a kernel WARNING in bpf_trampoline_multi_detach and leaves the trampoline link improperly managed. Only systems where a user holds BPF privileges (CAP_BPF or CAP_SYS_ADMIN) and uses the newer tracing_multi/fentry-multi link types are affected, with local access required (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L); there is no remote reachability and no unprivileged path on hardened configurations. The observable impact is a warning and a leaked or mismanaged link rather than attacker-controlled memory corruption, and no public exploit code was identified at time of analysis.
A race condition in the Linux kernel's RDMA/rxe (Soft-RoCE) responder state machine lets a single received packet be re-executed and re-completed once per posted receive WQE when a queue pair transitions to the error state mid-completion, producing hundreds of duplicate IB_WC_SUCCESS completions that are indistinguishable from genuine receives, then a kernel NULL pointer dereference in copy_data()/send_data_in() once the receive queue is exhausted. Kernels from 6.4 (starting with commit 49dc9c1f0c7e) up to the fix are affected; Soft-RoCE is not enabled by default in most deployments, and our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, well below the vendor's 8.2 (AV:N/AC:L/PR:N/UI:N), because triggering requires an established Reliable Connection queue pair, an active receive queue, and a narrow disconnect/receive timing window rather than a single request. There is no CISA KEV listing and no public exploit code identified at time of analysis.
A corrupted HFS+ filesystem image can cause a heap out-of-bounds write in the Linux kernel's hfsplus driver when the catalog thread record located by CNID in hfsplus_delete_cat() is not validated before its nodeName.length is used to rebuild a catalog delete key. The vulnerable path is reached with str == NULL, which happens when the last open reference to an unlinked HFS+ hardlink backing inode is closed, and is limited to Linux systems that have the hfsplus module (CONFIG_HFSPLUS_FS) loaded and are willing to mount an attacker-supplied or corrupted HFS+ volume; mounting untrusted images normally requires CAP_SYS_ADMIN or an unprivileged automount/udisks configuration. Local access and a crafted image are both prerequisites, and no public exploit code was identified at time of analysis; note that HFS+ (HFS Plus) is distinct from the newer Apple File System (APFS). The vendor-assigned CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is judged to overstate real-world risk; exploitation requires mounting a malicious image and then triggering unlinked-hardlink cleanup, so no public exploit code was identified at time of analysis and the flaw is not exploitable against default configurations that never mount untrusted HFS+ media.
A heap out-of-bounds write in the Linux kernel's CXL Features subsystem (cxlctl_get_feature) lets a local user who can reach the FWCTL_RPC interface corrupt kernel heap memory by supplying a small fwctl_rpc.out_len alongside a large cxl_mbox_get_feat_in.count, causing the CXL device to write past the end of a kvzalloc()'d buffer. Only systems running kernel 6.15 or later with the CXL Features subsystem built in and a Features-capable CXL device bound are affected, and the attacker must hold a handle to the fwctl character device (/dev/fwctl) and the privileges required to use it (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H, 7.8). This is a genuinely attacker-controlled out-of-bounds write rather than a probe or error-path crash, but it is not remotely reachable, no public exploit has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV).
Incorrect kernel virtual address computation in the Linux kernel DAX/fsdev direct_access path (__fsdev_dax_direct_access) causes the returned kaddr to be wrong for device-dax devices configured as multi-range with physical gaps between ranges, since the code adds a device-linear byte offset to virt_addr (the __va of ranges[0]) instead of translating the physical address directly. This is a local-only correctness/memory-safety bug: the vendor-assigned CVSS is 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), while independent assessment rates it CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H because the flaw is only reachable on a non-default, hardware/topology-specific multi-range layout and the dominant effect is memory corruption or kernel instability rather than clean confidentiality loss. Exploitation requires a local principal with permission to perform DAX direct_access on such a device; no public exploit code was identified at time of analysis and there is no confirmed active exploitation.
A double-free in the Linux kernel's Intel IPU6 media driver (media: ipu6) occurs when the isys/psys auxiliary-device initialization fails and its error-unwinding path frees the platform data pointer a second time. Kernels built with the ipu6 bridge - introduced in Linux 6.10 and used on systems with Intel IPU6 / MIPI camera hardware - are affected, and reaching the flaw requires local, high-privileged access plus a specific driver-init failure (MMU initialization or auxiliary_device_add() failure) rather than an ordinary attacker-controlled syscall. No public exploit code has been identified at time of analysis; the assessed impact is limited to a low-availability fault (local, high privileges, high attack complexity) rather than the 7.8 score carried in the raw NVD feed.
A buffer overflow in the Linux kernel's iwlwifi MEI coexistence code (iwlmei) lets a party able to inject SAP messages over the MEI bus trigger an out-of-bounds memory write by declaring a message length larger than the driver's local buffer, which the code reads without validating. Affected systems are limited to kernels built with CONFIG_IWLMEI on Intel hardware where CSME/AMT coexists with the Wi-Fi device - a non-default, enterprise-oriented configuration; standard iwlwifi deployments are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but the flaw is remotely reachable only from a compromised CSME/ME firmware or equivalent MEI-side attacker, so the practical prerequisites are substantial even though the vendor score of 8.4 (AV:L/AC:L/PR:N) overstates ease of reach. Vendor-released fixes are available in 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
Use-after-free in the Linux kernel's Userspace I/O (uio) subsystem can expose freed kernel memory and crash the kernel when a local process opens /dev/uioX at the exact moment a UIO device registration fails at a step after device_add() has already made the node visible to userspace. The failing path unwinds the device but leaves idev->info pointing at the driver's caller-owned struct uio_info, so an already-open file descriptor can later follow that dangling pointer into memory the driver has freed after seeing registration fail. Exploitation requires local access with low privileges (CVSS PR:L per the assessed vector), a difficult-to-win kernel race (AC:H), and a UIO driver that genuinely hits a post-device_add() setup failure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the independent assessment rates real-world risk as low-to-moderate despite the vendor-associated 7.0 CVSS score.
An out-of-bounds read in the Linux kernel's software_node_get_reference_args() helper is caused by a bounds check that fails to reject an index value of -1 (UINT_MAX), allowing the property reference array to be read past its end. Only local users with some existing privileges (CVSS PR:L) who can reach this niche fwnode/software-node code path can trigger it, and exploitation is rated high complexity because a specific caller-supplied index is required; the practical outcome is primarily a kernel crash or denial of service, with at most limited information disclosure. No public exploit code has been identified at time of analysis, the flaw is not confirmed as actively exploited (not in CISA KEV), and vendor patches are available in the listed stable kernel releases.
A memory-corruption bug in the Linux kernel's BPF arena allocator allows a local attacker who can load BPF programs (effectively CAP_BPF on kernels from about 6.9 onward) to corrupt the arena free tree and cause a subsequent allocation to hand back an address below the arena mapping. The flaw is reached by calling bpf_arena_free_pages() with a scalar arena address whose value falls below the low 32 bits of the arena base; the masked reconstruction then produces full_uaddr below user_vm_start, and the existing upper-end clipping converts this into an out-of-range free-tree offset. Privileges are required (CVSS PR:L, AV:L), there is no public exploit code identified at time of analysis, and the issue is not confirmed as actively exploited (not in CISA KEV); the vendor rates it 7.8 while our independent assessment rates it lower (C:L/I:L/A:H) because exposure is confined to callers already trusted to load BPF programs.
A use-after-free in the Linux kernel's dw-edma (DesignWare eDMA) DMA engine driver lets a local user who can submit and then synchronously terminate DMA transfers trigger a late virt-dma completion callback that dereferences client state already freed, risking kernel memory corruption or a denial of service. Kernels built with the dw-edma driver (present since Linux 5.3) on platforms exposing the corresponding PCIe/SoC eDMA controller and running a DMA client that submits transfers are affected; fixes are available in stable releases 6.6.157, 6.12.110, 6.18.52, 7.2.6 and in mainline 7.3-rc1. The vendor-listed CVSS of 8.8 (AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H) substantially overstates the risk: exploitation requires local access and winning a narrow race in which a deferred STOP must reach the interrupt handler after the client's state has been freed, and no public exploit has been identified at time of analysis.
A memory-safety flaw in the Linux kernel's Amlogic Meson ASoC sound-card driver (meson_card_reallocate_links()) allows a local user on affected Meson hardware to trigger a use-after-free and double free of card->dai_link, but only when the first krealloc() succeeds and relocates the array while the second krealloc() then fails under genuine kernel memory exhaustion. Because the trigger is an allocator-conditioned failure on the driver's probe/error path with no attacker-controlled data path and no remote reachability, our independent assessment rates the real-world impact as limited to availability (assessed CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), notably lower than the 7.4 that reflects the raw memory-safety class. There is no public exploit code and no confirmed active exploitation at time of analysis; vendor-released fixes are available in stable branches 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110 and 6.18.52 (plus 7.3-rc1).
In the Linux kernel's Intel Omni-Path hfi1 RDMA driver, a local user able to submit SDMA/verbs transmit work requests can reach an error path where sdma_txinit_ahg() fails to initialize the TX request but set_txreq_header_ahg() ignores that failure and reports success, so the caller continues operating on an uninitialized txreq and the kernel can corrupt memory and crash, producing a denial of service. Exposure is limited to hosts with an Intel Omni-Path fabric adapter, the hfi1 driver loaded and in active use, and a user with the privileges needed to issue RDMA work requests (PR:L) - and the bug only fires when an internal SDMA initialization failure actually occurs, which is not attacker-supplied input and is hard to force on demand. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the vendor scores this 7.8, while our independent assessment rates it as an availability-only impact (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) and considers the vendor severity overstated for this specific defect.
An out-of-bounds read in the Linux kernel's RDMA/rxe (Soft-RoCE) driver lets a local unprivileged user who can post work queue entries directly into a user queue pair's submission ring drive copy_data() to index past the per-WQE scatter/gather array using an attacker-controlled cur_sge value or an oversized num_sge, producing a vmalloc out-of-bounds read that can crash the kernel. Exploitation is strictly local and requires the rdma_rxe module to be loaded with an rxe device configured plus the ability to open the InfiniBand uverbs interface and create a user-space QP that posts a payload-bearing WQE - a niche, non-default configuration; kernel-created QPs already enforce the num_sge bound. There is no public exploit code or confirmed active exploitation identified at time of analysis, and the issue was reported and fixed upstream, with patched stable releases including 6.1.188, 6.6.157, 6.12.110 and 6.18.52, so this is best treated as a low-priority local denial-of-service issue with limited confidentiality exposure.
Out-of-bounds memory reads in the Linux kernel ACPI processor IOAPIC hotplug lookup affect systems with x86 IOAPIC/CPU hotplug support where MADT and _MAT records are parsed. A local attacker with privileges (PR:L) and the ability to supply malformed ACPI firmware data-an IOAPIC entry whose declared generic-header length exceeds the available record range or that lacks the full fixed IOAPIC body-can trigger kernel memory over-read (C:L) and a likely crash or system unavailability (A:H); integrity impact is absent. This is a moderate-priority defensive kernel hardening fix rather than an urgent remotely exploitable flaw: exploitation is local only with high attack complexity and depends on firmware or privileged hotplug control, and no public exploit or active exploitation has been identified at time of analysis.
Kernel stack corruption in the Linux kernel on RISC-V builds compiled with CONFIG_CFI_CLANG is reachable through a BPF program that performs a tail call: prog->bpf_func already lands past the kcfi instruction during setup, so folding that instruction into the tailcall jump offset again overshoots by 4 bytes and skips the stack-pointer adjustment, leaving a corrupted kernel stack. Triggering it requires a local actor able to load and run the offending BPF program (CVSS PR:L, typically CAP_BPF/CAP_SYS_ADMIN), a RISC-V kernel, and CONFIG_CFI_CLANG; non-RISC-V kernels and builds without CFI_CLANG do not execute the affected codepath. Independent assessment rates this a local, low-severity-in-practice reliability/corruption bug whose practical impact is primarily availability (crash/disrupted stack), with limited integrity impact, and no public exploit identified at time of analysis.
A use-after-free race in the Linux kernel RDMA core lets a local, low-privileged user who can create and destroy completion queues trigger memory corruption during CQ teardown in ib_destroy_cq_user(), because vendor-specific CQ resources may be freed before the CQ is removed from the restrack registry. The bug is reachable only on hosts with the InfiniBand/RDMA stack loaded and an RDMA device exposing the uverbs/netlink restrack interfaces, and only through a narrow timing window, so per independent assessment it is a low-priority local denial-of-service rather than the 7.8 vendor score suggests (assessed vector AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis; vendor-released fixes exist in stable releases including 6.1.188, 6.6.157, 6.12.110, 6.18.52 and 7.2.6.
Use-after-free in the Linux kernel's RDMA core (ib_destroy_srq_user()) allows a local attacker who can allocate shared receive queues to race SRQ teardown against a concurrent netlink/restrack lookup, potentially crashing or destabilizing an RDMA-capable host. The assessed vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) indicates an authenticated local actor with low privileges on a machine exposing an RDMA stack (InfiniBand, RoCE, or iWARP), with impact limited to availability - the high-complexity timing race makes reliable exploitation unlikely and no memory-corruption outcome is confirmed. No public exploit code and no confirmed active exploitation were identified at time of analysis; RDMA hardware and drivers are uncommon outside datacenter and HPC environments, which sharply narrows the exposed population.
A use-after-free race in the Linux kernel RDMA core (ib_free_cq()) can crash or destabilize hosts that use InfiniBand, RoCE, or iWARP fabrics. An authenticated local user who can query completion queues through the RDMA netlink resource-tracking (restrack) interface can win a narrow timing window against a concurrent CQ teardown, because rdma_restrack_del() is executed only after vendor-specific CQ resources have already been freed, leaving the CQ briefly reachable via restrack. The assessed impact is denial of service only (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) given the non-deterministic race and the local-only reach on RDMA-configured systems; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
A use-after-free race in the Linux kernel's RDMA core (ib_core) lets a local user who can query Protection Domains over the RDMA netlink/restrack interface dereference a PD object after its vendor-specific resources have already been freed, during the narrow window at the end of ib_dealloc_pd_user(). Only hosts with the RDMA subsystem active (InfiniBand, RoCE, or iWARP drivers loaded) and reachable by the attacker's context are affected, and winning the timing window is non-deterministic, so the realistic outcome is a kernel crash or denial of service rather than memory corruption with a clear privilege-escalation path. Per the CVSS vector the attacker must already hold local credentials (PR:L, AV:L); no public exploit code has been identified at time of analysis, and the bug should be treated as a modest-priority local reliability/memory-safety issue despite the vendor's 7.8 score.
Error-path resource cleanup in the Linux kernel's Intel INT3400 (DPTF) thermal driver leaves per-ODVP sysfs files and their backing storage allocated when probe fails after evaluate_odvp() has already run - for example when thermal_tripless_zone_device_register() or a later probe resource registration fails. The affected code is present only on Intel platforms that expose the INT3400 ACPI device and is reached solely through ACPI firmware or hardware-driven probe failures, not attacker-supplied input, so impact is bounded to leaked sysfs objects and kernel storage with no confidentiality or integrity effect. The assessed vector (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L) reflects a low-severity local resource leak rather than a memory-safety flaw; exploitation requires high privileges on the local system, no public exploit identified at time of analysis, and vendor-released stable patches are available for the maintained branches.
A double-free in the Linux kernel's IPsec/xfrm device direct-output path (xfrm_dev_direct_output()) can crash the affected host when a netfilter hook drops an outgoing packet whose skb ownership has already been transferred - the function frees the skb anyway, corrupting memory and invalidating any other owner. Affected kernels are the 6.6.x line from 6.6.85 up to (but not including) 6.6.157, 6.12.x from 6.12.21 to before 6.12.110, and 6.13.9 through 6.14, plus the corresponding mainline commit ranges; exploitation requires IPsec crypto/packet offload configured on the egress device together with a netfilter/nftables rule that drops on that path, so real-world reach is narrow and the assessed impact is a local denial of service (host crash) rather than remote code execution or data exposure. Vendor-supplied CVSS is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), which is contradicted by the description, the code semantics, and the independent assessment (AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H). No public exploit code and no CISA KEV entry were identified - no public exploit identified at time of analysis - and vendor patches are available as 6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1 or later.
Failed object teardown in the Linux erdma (Alibaba Elastic RDMA Adapter) driver leaks queue buffers, MTTs, doorbells, and the STAG, QPN, CQN and AHN identifiers, because erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr() and erdma_destroy_ah() return early when erdma_post_cmd_wait() fails instead of completing software-side release. The leak path is only reachable when a device destroy command times out, an event that clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue; the RDMA core then keeps the object after the failed destructor, and forced uverbs cleanup nulls the pointers so the resources become unreachable. This is a hardware/firmware fault condition rather than an attacker-injectable bug, limiting practical risk: local access to a host with the erdma driver loaded is required (CVSS PR:L, AV:L, AC:H), no public exploit code was identified at time of analysis, and the vendor score of 7.0 (C:H/I:H/A:H) substantially overstates impact, which our assessment confines to a local resource/availability effect (A:L).
Signed integer overflow in the Linux kernel's mlx5 RDMA driver (RDMA/mlx5) lets a local user who already holds RDMA access to a Mellanox/NVIDIA ConnectX device create a user QP with a buffer smaller than the hardware will write into, producing a local out-of-bounds write and memory corruption (CVSS 3.1 base 7.8; our independent assessment scores it AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H). Only hosts exposing an mlx5 device through the verbs uAPI (for example /dev/infiniband/uverbs*) to a user with RDMA permissions are exposed; the vector is local and not network-reachable. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but vendor patches are available for all supported stable branches.
A race condition in the Linux kernel's NVIDIA Tegra241 CMDQV (vCMDQ) SMMUv3 driver allows a local user with iommufd/VFIO privileges to trigger a NULL pointer dereference or use-after-free by destroying or creating a user VINTF at the same moment an error interrupt fires. The tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] without synchronization, and deinit_vintf() returns idx to the IDA before clearing the slot, so a reused index can be published and then clobbered with a stale NULL store. Per the independent assessment the realistic outcome is a host-kernel crash (denial of service) on Grace-class ARM64 hardware; the assessed vector is AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, reflecting the narrow timing window and the local privileged device access required. No public exploit code or confirmed active exploitation was identified at time of analysis.
The Linux kernel's tegra241-cmdqv IOMMU driver (the NVIDIA Grace vCMDQ virtualization acceleration path) mishandles vSID-to-Stream-ID mapping in tegra241_vintf_init_vsid() when the passed-through device's master exposes anything other than exactly one physical Stream ID: zero streams makes master->streams a ZERO_SIZE_PTR that is dereferenced out of bounds, while multiple streams results in only streams[0] being mapped, so guest vSID invalidations silently miss the remaining ATC/IOTLB entries. The consequence is a kernel-level out-of-bounds read (availability impact and limited information exposure) plus stale/incompletely invalidated IOMMU translation caches for a passthrough guest. Exploitation is not remote and not trivial: it requires local privilege sufficient to attach devices via iommufd/VFIO and configure a guest passthrough on tegra241 hardware with a non-standard device stream configuration, and no public exploit code or confirmed active exploitation exists at time of analysis. Note that the vendor CVSS of 8.8 materially overstates real-world risk relative to the independent assessment, which scores it AV:L/PR:L with scope unchanged and only low confidentiality/integrity impact.
A use-after-free in the Linux kernel's RDMA/rxe (Soft-RoCE) driver can be triggered by a local user who registers a memory region with On-Demand Paging enabled and then causes the ODP page-initialization to fail. When rxe_odp_init_pages() errors out, rxe_odp_mr_init_user() frees the user memory object but leaves the dangling pointer in mr->umem, so the subsequent MR cleanup path calls ib_umem_release() on freed memory and reads stale fields such as umem->is_dmabuf, which the kernel's own CVSS vector rates as 7.8 while our independent assessment scores it lower (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) because the failure path must be deliberately induced and the rxe driver plus ODP are rarely enabled in production. Exploitation is limited to local authenticated users with the privilege to issue ibv_reg_mr against an rxe device; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. Vendor patches are available in the stable kernel commits referenced by the advisory.
Malformed NILFS2 filesystem images can drive the Linux kernel's nilfs2 super-root block parser to read past the end of the super-root block, because the super-root inode's metadata size is trusted before nilfs_read_inode_common() validates it; the fix rejects inode sizes whose computed on-disk footprint exceeds the filesystem block size. Exploitation requires a local user to mount an attacker-supplied image (assessed vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H), so this is not reachable by a remote, unauthenticated network attacker, and the realistic outcome is a kernel crash or a bounded kernel-memory disclosure rather than code execution or reliable data theft. nilfs2 must be compiled in or loaded, which is uncommon outside specialized storage deployments, and no public exploit identified at time of analysis or confirmed actively exploited (CISA KEV) status was found in the available intelligence.
Out-of-bounds memory access in the Linux kernel's IB/isert iSER (iSCSI-over-RDMA) target allows a remote attacker who can reach an exposed iSER portal over an RDMA fabric to trigger reads beyond a fixed-size receive descriptor, and in the immediate-data path to hand an oversized scatterlist to the SCSI backend, potentially corrupting the backing store. Affected systems are Linux targets running the isert target driver with a configured LUN/backing store; the attacker must complete login and reach the full-feature phase, then negotiate a large TargetRecvDataSegmentLength and send a PDU whose BHS-declared data-segment length exceeds the bytes actually received. Vendor-released fixes exist for the stable branches (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.3-rc1), no public exploit code has been identified at time of analysis, and the vendor CVSS of 9.1 (AV:N) is assessed as overstated because exploitation requires RDMA-fabric adjacency rather than open-internet reachability.
A pre-authentication out-of-bounds read in the Linux kernel iSER (iSCSI Extensions for RDMA) target login path lets an attacker who can reach the RDMA fabric crash the host kernel, producing a denial of service. Only hosts exporting an LIO/target-core iSCSI target over the iSER RDMA transport (RoCE, iWARP, or InfiniBand) are affected; iSCSI targets served over plain TCP are explicitly not vulnerable because that path validates the declared login length with iscsi_target_check_login_request(), while isert never calls it. The vendor rates this 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H); our independent assessment keeps AV:N/AC:L/PR:N/UI:N but treats impact as availability-only (C:N/I:N/A:H), and no public exploit has been identified at time of analysis - though the upstream commit includes a deterministic soft-RoCE/KASAN reproducer.
Out-of-bounds reads in the Linux kernel's ath11k Qualcomm WiFi-6 driver allow a malformed WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT from device firmware to read past the bounds of a TLV payload. The flaw exists because no TLV policy entry enforces a minimum length for this event struct, and the firmware-supplied num_vdevs field is used directly as a loop bound over the vdev_ids array without validation; per the CVSS vector this is a local (AV:L) attack with no privileges required (PR:N), though the independent assessment rates it AC:H/C:L rather than the vendor's AC:L/C:H framing. Triggering it requires an affected Qualcomm ath11k adapter running a firmware image that emits an inconsistent num_vdevs value or event length - meaning a malicious or genuinely buggy firmware blob, not a remote network peer or unprivileged userspace API - and no public exploit has been identified at time of analysis. The kernel reads are limited to disclosure of adjacent memory (information leak) plus a potential denial-of-service if the out-of-bounds access faults.
Failure at the last stage of device probe in the Linux kernel's rtlwifi PCI driver leaves wireless registrations dangling because an incorrect goto label in rtl_pci_probe() skips rollback of rtl_init_rfkill(), ieee80211_register_hw() and rtl_debug_add_one(). The result is a resource leak on an already-registered mac80211 hardware object, a stale rfkill instance and a leftover debugfs entry, which can produce a use-after-free or denial-of-service condition on affected systems running Realtek rtlwifi PCI hardware. Independent assessment rates this as low impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) because the buggy path is local, requires an actual probe-time failure rather than attacker-supplied input, and needs a local user with low privileges plus Realtek rtlwifi PCI hardware present; no public exploit code and no confirmed active exploitation were identified at time of analysis.
In the Linux kernel's MHI host bus driver, an error path in mhi_register_controller() fails to unregister the controller device from sysfs when creation of the optional trigger_edl attribute fails, leaving a partially registered device behind in addition to dropping the device reference. The affected code is only reachable on systems where the MHI host bus driver is loaded and bound to supported Qualcomm modem/WWAN/PCIe-endpoint hardware, and the trigger requires an unlikely failure of sysfs_create_file() (for example an allocation failure under memory pressure) rather than attacker-controlled input. Although the vendor assigned a 7.0 High score, our independent assessment rates real-world risk as low: local access (AV:L), high complexity (AC:H), low privileges required (PR:L), and availability-only impact (C:N/I:N/A:L); no public exploit code has been identified at time of analysis and there is no evidence of active exploitation (not in CISA KEV).
Heap memory corruption in the Linux kernel ath12k WiFi7 driver stems from a stride mismatch in ath12k_wmi_mac_phy_caps_parse(): the mac_phy_caps buffer is sized from a firmware-clamped length, while the memcpy write and the subsequent reader both advance by full-struct pointer arithmetic, so firmware-supplied WMI mac_phy_caps TLVs shorter than sizeof(struct ath12k_wmi_mac_phy_caps_params) cause out-of-bounds heap writes on every slot after the first. Affected systems are those running the in-tree ath12k driver (introduced in Linux 6.3) with Qualcomm WiFi7 hardware such as WCN7850; the trigger is firmware/adapter-controlled data rather than network traffic, which is why the independent assessment rates the issue AV:L/PR:H with High availability impact only, rather than the vendor's 8.4 vector with PR:N and full C/I/A. No public exploit code has been identified at time of analysis, there is no CISA KEV entry, and vendor-released fixes are available in stable releases 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
Heap out-of-bounds write in the Linux kernel ath11k WiFi driver (Qualcomm WiFi6 hardware) allows a malicious or malfunctioning firmware image to write kernel memory past the end of the allocated mac_phy_capabilities buffer while processing a WMI service-ready-ext message. The affected code has shipped since Linux 5.6 (commit 5b90fc760db5a969ed26d70f8e62c91915f012bd) and is fixed in stable versions 6.12.110 and 6.18.52, 7.2.6, and mainline 7.3-rc1; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV. The upstream CVSS 3.1 score is 8.4 with C:H/I:H/A:H, but our assessment rates it lower (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H) because exploitation requires control of the firmware/TLV stream the chip presents to the host, not ordinary network traffic or a normal unprivileged local API, and the fix was compile-tested only so real-world triggerability is not vendor-confirmed.
Local attackers holding CAP_BPF can trigger a use-after-free race in the Linux kernel's BPF link subsystem, where bpf_link_show_fdinfo() and bpf_link_get_info_by_fd() read link->prog without holding a lock while bpf_link_update() concurrently swaps and frees that program, yielding a crash (availability loss) or disclosure of freed kernel memory. Kernels from v5.7 up to the fixed backport releases (6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1) are affected; exploitation is gated by a narrow, probabilistic timing window and requires local access plus the ability to create, read, and update a BPF link. There is no remote vector, no confirmed active exploitation (not in CISA KEV), and no public exploit code identified at time of analysis.
A DMA-IOMMU error-handling defect in the Linux kernel allows a failed atomic DMA pool allocation to go undetected, so an invalid page can be handed to the IOMMU mapping path and trigger kernel memory faults resulting in denial of service. Affected builds are those exercising IOMMU-backed non-blocking, non-coherent DMA allocations (dma_alloc_from_pool()), and the bug only manifests when that pool allocation actually fails under memory pressure; exploitation requires local access sufficient to drive device DMA traffic (PR:L) plus a genuine pool-exhaustion condition that is not directly attacker-controlled (AC:H), giving an assessed availability-only impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code has been identified at time of analysis, and vendor-released fixes exist in the stable branches listed below.
A DMA-subsystem correctness flaw in the Linux kernel causes swiotlb dynamic pools to store an incorrect virtual address when a decrypted pool is allocated from the DMA atomic pool in atomic context, leading to failed chunk recognition on the pool free path. Only kernels built with CONFIG_DMA_DIRECT_REMAP (typical of confidential-computing/encrypted-DMA or certain ARM remapped-atomic-pool configurations) are affected, and the bug is locally reachable with no user-interaction or attacker-controlled input described; the independent assessment rates it as low severity (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) whose worst realistic outcome is atomic-pool resource leakage rather than code execution or data exposure. No public exploit code was identified at time of analysis, and vendor patches are available (Linux 6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1).
A timing-dependent race in the Linux kernel's misc/sgi-gru driver lets a local, low-privileged user who holds a GRU context trigger a lockless, reference-free walk of that process's page tables from interrupt context, so concurrent page-table modification or teardown can make the walker dereference stale page-table entries. Successful exploitation is expected to produce a kernel crash (availability impact) with limited potential information exposure, and requires a race that is timing-dependent rather than deterministically controllable. Exposure is narrow: the vulnerable code path is only reachable on systems with SGI GRU hardware (SGI UV/Altix x86-64 NUMA platforms) and the sgi-gru driver loaded; no public exploit has been identified at time of analysis, and vendor patches are available in 6.12.110, 6.18.52, 7.2.6, and 7.3-rc1.
An out-of-bounds memory access in the Linux kernel's MediaTek mt76/mt7921e PCIe Wi-Fi driver can crash (kernel panic / denial of service) the local machine when a PCIe Advanced Error Reporting (AER) fault hangs the bus and register reads return 0xFFFFFFFF. The affected code is the mt7921e MAC-reset recovery path (mt7921_mac_reset_work -> mt7921e_mac_reset -> mt7921_wpdma_reset -> mt76_dma_rx_reset), which trusts the bogus DMA queue index and dereferences q->desc[]/q->entry[] out of range. Impact is limited to a local denial of service on systems that ship this driver and actually experience a hardware PCIe fault - this is a fault-tolerance defect, not an attacker-steerable memory-corruption issue - and no public exploit identified at time of analysis. Vendor-released patch: Linux 6.18.52, 7.2.6, and 7.3-rc1.
Linux kernel's mt76/mt7915 MediaTek Wi-Fi 6 driver can write an underflowed spatial-stream count (255) into firmware beamforming station records when an adjacent peer advertises a VHT/HE MCS map with all spatial-stream fields set to 0x3, corrupting the driver's view of that station's beamforming state. Exploitation requires radio adjacency (AV:A) and unauthenticated access per the CVSS vector (PR:N), with the attacker acting as an associating peer that reaches the mt7915_mcu_get_sta_nss beamforming station-record programming path; no public exploit code exists and no active exploitation is confirmed. The vendor rates this 7.1 with high availability impact, but independent assessment downgrades the severity because the effect is confined to firmware beamforming state with no memory-safety corruption, code execution, or confidentiality exposure.
A race condition in the Linux kernel's MediaTek mt76 WiFi driver can crash or hang affected systems, producing a denial of service by disrupting the RXDMAD_C buffer recycling path used by RRO (Receive Reorder Offload) data queues. The flaw affects kernels carrying the vulnerable mt76 code, notably the 6.18 series where the WiFi7/mt7996-class offload path is active, and it is exploitable by an unauthenticated attacker within adjacent wireless range (CVSS 3.1 AV:A/AC:H/PR:N/UI:N, with the independent assessment scoring availability-only impact, C:N/I:N/A:H). The trigger depends on winning a timing-sensitive race between the direct page-pool recycle and the buffer's owning NAPI, so it is not a deterministic single-packet trigger; there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Missing lock scope in the Linux kernel's mt76 mt7996 Wi-Fi 7 driver lets a reset/recovery path race with a channel change, allowing DMA ring descriptors and tokens to be corrupted. Only systems running a kernel from 6.4 onward on MediaTek MT7996/MT7992 (Wi-Fi 7) hardware are affected, and the trigger is a hardware/firmware L1 System Error Recovery event in mt7996_mac_reset_work() that must overlap an in-progress __mt76_set_channel() call - a narrow, non-attacker-controlled timing window rather than a packet-delivery path. Both the vendor vector's adjacent-network, unauthenticated profile (CVSS 8.8) and the 'Information Disclosure' tag overstate the practical issue: our independent assessment rates this as a concurrency/reliability defect (AV:A/AC:H, confidentiality and integrity not confirmed, availability High), and no public exploit has been identified at time of analysis. Vendor-released fixes are available in Linux 6.18.52, 7.2.6, and 7.3-rc1.
An out-of-bounds stack write exists in the x86 BPF trampoline code of the Linux kernel: btf_distill_func_proto() permits a function argument of up to 16 bytes, so a 128-bit scalar such as __int128 arrives with arg_size == 16, but the trampoline's register save-area sizing logic still assumes a single register for that argument. The result is an under-allocated save area that save_args() overruns into adjacent stack slots, corrupting the trampoline's own kernel stack frame. Exploitation requires local privilege sufficient to load and attach BPF programs (CAP_BPF or equivalent, matching the PR:L vector) on an x86 system, plus attaching an fentry/fexit-style trampoline to a kernel function whose prototype actually passes a 128-bit scalar - a rare signature. There is confirmed no public exploit identified at time of analysis; this is a local, privileged-attach memory-corruption issue rather than the 'Information Disclosure' tag some feeds applied to it, and vendor fixes are available in the 6.1, 6.12, 6.18 and 7.x stable lines.
Linux kernel Wi-Fi driver bug in the MediaTek mt76/mt7915 (mt7915e) TWT handling allows an adjacent, associated 802.11 peer to corrupt kernel memory by triggering a Target Wake Time agreement that the device MCU rejects, leaving a TWT flow linked on dev->twt_list while its flowid_mask is never set. The affected versions are Linux kernels carrying the mt7915 TWT support (introduced around 5.16) prior to the fixed releases 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1. Exploitation requires over-the-air adjacency and association plus the MCU-reject error path and a slot-reuse/memset race window, so it is not remotely reachable from the Internet; no public exploit code has been identified at time of analysis, and the vendor's CVSS 8.8 (C:H/I:H/A:H) overstates impact relative to the described list corruption and dangling-entry condition, which our assessment scores as availability-only (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H).
A use-after-free in the Linux kernel's mt76 mt7915 Wi-Fi driver (media/mediatek/mt7915) can crash the kernel, giving a local denial of service, when an ext-PHY-capable MediaTek MT7915 adapter registers its extension PHY successfully but then fails in a later initialization step (mt7915_init_debugfs() or mt7915_coredump_register()). The bug is in the error-unwind path: free_phy2 calls ieee80211_free_hw() on the ext PHY hardware while it is still registered with mac80211, because mt76_unregister_device() only tears down the main hw. Exploitation is tightly constrained - there is no remote vector and no user-controlled input; the failure window depends on internal allocation/registration faults (resource pressure or transient probe errors) during module load, and the assessed impact is kernel crash rather than attacker-directed code execution or data disclosure. No confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor's 7.0 High rating is not supported by this assessment, which rates the issue as low priority.
A teardown-ordering defect in the Linux kernel's cfg80211 wireless configuration layer allows a local user with wireless configuration privileges (CAP_NET_ADMIN) to desynchronize PMSR (peer measurement / FTM ranging) request state: cfg80211_stop_p2p_device() and cfg80211_stop_nan() tear down the mac80211 subinterface before aborting pending measurement requests, after which cfg80211 still frees the request while the lower driver can retain a stale pointer. The flaw affects kernels from roughly 5.0 through the fixed 6.18.52, 7.2.6, and 7.3-rc1 releases and requires a driver/hardware combination supporting PMSR plus P2P or NAN. The vendor's 7.8 score (C:H/I:H/A:H) reflects an assumed memory-corruption outcome, but our independent assessment scores it 7.8 → 6.2-equivalent as availability-only (AV:L/AC:H/PR:L/UI:N/C:N/I:N/A:H): a local reliability/denial-of-service bug rather than the high-impact information disclosure implied by the 'Information Disclosure' tag; no public exploit has been identified at time of analysis and there is no CISA KEV listing.
Malformed coreboot firmware tables can drive the Linux kernel's coreboot_table driver into mapping and parsing memory outside its declared platform resource, producing out-of-bounds reads that disclose kernel memory and crash the system on affected coreboot-based platforms. The flaw lives entirely in the boot/probe-time firmware parsing path (drivers/firmware/google/coreboot_table.c), so it is not reachable from an ordinary unprivileged local process: an attacker must be able to supply or corrupt the coreboot table itself, via firmware reflash, a malicious or compromised firmware image, or physical access, and the vulnerable code is absent altogether on systems that do not boot coreboot firmware. No public exploit code and no confirmed active exploitation were identified at time of analysis; vendor-released fixes are available in the stable kernels 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1.
A posted-write ordering bug in the Linux kernel DesignWare (dwc) PCIe endpoint driver can drop or misroute an MSI interrupt write when the iATU outbound window mapping the cached MSI target address is torn down and reprogrammed. Only systems running a Synopsys DesignWare PCIe controller in ENDPOINT mode on the MSI (not MSI-X) interrupt path are affected, and triggering it requires a narrow hardware/fabric race in which the Root Complex changes the cached MSI target address while a posted MSI write is still in flight - a legitimate reconfiguration event rather than attacker-supplied input. No public exploit code has been identified at time of analysis; the vendor CVSS of 8.2 is assessed as inflated, and the real-world impact is limited to reliability/ordering on embedded and SoC endpoint deployments, with no applicability to standard PCIe root-complex hosts such as servers, desktops, or laptops. The issue is resolved by reading back from the mapped MSI window before unmapping the iATU entry, mirroring the existing MSI-X flush fix.
A use-after-free race in the Linux kernel's HID subsystem allows a crafted or faulty HID device to crash the kernel: hid_device_io_start() permits report callbacks to run concurrently with driver probe, and if that probe then fails, __hid_device_probe() frees driver resources including the hidraw object and clears hdev->driver without first excluding an in-flight callback, so a report entering hidraw_report_event() ends up taking a freed list lock. Exploitation requires an attacker to supply or control a physical USB HID device (or be within Bluetooth HID range) whose driver probe fails while a report callback is executing, making this a local/adjacent availability issue - a kernel crash - rather than a remotely reachable or confidentiality-impacting one; no public exploit code and no confirmed active exploitation were identified at time of analysis. Upstream fixes have been released across the maintained stable branches.
A local use-after-free combined with a memory leak in the Linux kernel's blk-cgroup (block cgroup) subsystem allows a privileged local actor to crash or destabilize the kernel by racing IO-scheduler activation against concurrent block-cgroup deletion. Exploitation requires writing to /sys/block/<dev>/queue/scheduler (normally root/CAP_SYS_ADMIN) while simultaneously triggering blkcg teardown for a different blkg, and the corrupting path is only reachable through the ENOMEM rollback branch of blkcg_activate_policy(), so the attacker must also induce a policy-data allocation failure for one blkg during the window. Impact is limited to availability (kernel panic/UAF); there is no remote vector, no confidentiality or integrity loss, no public exploit identified at time of analysis, and no confirmed active exploitation.
A local privilege-holder can trigger a use-after-free race in the Linux kernel's block-cgroup (blk-cgroup) layer by switching a block device's IO scheduler at the same time a blkcg cgroup is being deleted; the race corrupts blkg reference counting and leads to an RCU callback being accelerated on a freed object, with the realistic outcome being a kernel panic or crash of the affected host rather than a controlled exploitation primitive. Affected are kernels in the vulnerable range spanning the 6.1, 6.2/6.3, 6.6, 6.12, 6.18 and 7.2/7.3 development trees (CPE cpe:2.3:a:linux:linux), and exploitation is constrained: the CVSS vector requires local access with high privileges (PR:H) and a hard-to-win timing window (AC:H), so repeated attempts may be necessary and reliability is inherently low. The vendor scores this 7.8 while the independent assessment rates it lower (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H, availability-only, roughly 4.1), there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, and vendor-released patches exist in the stable trees (for example 6.1.17, 6.2.4, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and 7.3-rc1).
Missing return-value validation in the Linux kernel's ublk userspace block driver lets a local actor who can drive a ublk block device pass an uninitialized struct iov_iter into ublk_copy_user_pages(), because import_ubuf() failures are silently ignored. Exploitation requires the ublk subsystem (CONFIG_BLK_DEV_UBLK) to be built or loaded and the attacker to control a userspace ublk server bound to a ublk device - by default this means holding CAP_SYS_ADMIN, or any user if the device was created with UBLK_F_UNPRIVILEGED_DEV. The practical outcome is a kernel crash from dereferencing garbage iov_iter fields (with a possibility of limited kernel memory disclosure), not reliable remote code execution; there is no network vector, and no public exploit identified at time of analysis, though the affected component is narrow enough that most general-purpose hosts are unaffected. The vendor-published CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) rates confidentiality and integrity impact high, while independent assessment is more conservative (6.5-level, AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H), treating availability loss from the crash as the dominant risk.