Intel
Monthly
Attestation bypass in PrivaSys Enclave OS Mini before wasm-v0.40.0 allows an attacker who already possesses a valid enclave RA-TLS private key to relay a genuine SGX/TDX attestation quote onto a TLS connection the attacker terminates, so a relying party accepts an attacker-controlled channel as the attested enclave. The root cause is a missing TLS-session channel binding (CWE-346): in challenge-response mode the quote's ReportData folded only the certificate public-key hash and the client nonce, so nothing in the quote committed to the specific handshake, making a relayed quote valid on any connection. CVSS 4.0 rates this 9.1 (network reachable, unauthenticated per PR:N, no user interaction, high confidentiality and integrity impact), but the independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and the AT:P metric correctly temper it: exploitation presupposes a prior enclave key compromise and a challenge-mode deployment, and no public exploit has been identified at time of analysis.
Incorrect DMA mmap handling in the Linux kernel's IB/hfi1 Omni-Path driver (PIO_CRED case) lets a local, authenticated user with access to the HFI character device crash the kernel with a corrupted page-table oops or, once only the offset arithmetic is corrected, permanently stall send-PIO transfers. Kernels from 6.3 onward that include the hfi1 driver are affected, but the fault is intermittent-it appears only when the hardware send-context index reaches 64 or 128-and requires Intel Omni-Path 100 hardware plus the PSM2 path to invoke hfi1_file_mmap(). No public exploit code was identified at time of analysis, EPSS is low (0.18%, 6th percentile), and vendor-released fixes exist in 6.6.158, 6.12.112, 6.18.54, 7.2.8 and 7.3-rc4; given the local-only vector, mandatory specialized hardware and intermittency, overall risk is assessed as moderate rather than high-priority.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
Local privilege escalation in Zephyr RTOS allows an unprivileged user-mode thread that holds access to the Intel time-aware GPIO (TGPIO) device object to perform two uncontrolled 8-byte supervisor-mode writes to attacker-chosen kernel addresses via the tgpio_pin_read_ts_ec() syscall. The syscall's verification handler omitted the K_SYSCALL_MEMORY_WRITE() check that the sibling handlers in the same file already perform, converting a benign timestamp read-back into a write-what-where primitive that can corrupt kernel data structures, escalate the calling thread to supervisor privilege, or crash the system. Exposed builds are narrow: CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y must both be set, and because the affected source file failed to compile from v3.6.0 until after it was repaired past v4.4.0, the realistically exposed population is v3.5.0 builds plus downstream trees that locally patched that build breakage; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though it is rated CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Ultraviolet CoCoS through version 0.8.2 contains a session-misbinding flaw in the intra-handshake attested TLS (aTLS) verification path for Intel TDX: the verifier fails to copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so any structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for that session. An unauthenticated remote counterparty (CVSS vector AV:N/PR:N) that can supply or relay such a quote - acting as the attesting party or replaying a previously captured or foreign quote - can therefore cause a relying party to release application data bound to an unintended attestation context, giving high confidentiality and integrity impact. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the vendor's 9.1 score (AV:N/AC:L) slightly overstates ease of exploitation versus our assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, since a valid TDX quote and use of the affected TDX aTLS branch are prerequisites. The issue is fixed in version 0.9.0.
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.
Linux kernel's Intel VT-d IOMMU scalable-mode probe failure path can leave context entries pointing to a freed PASID table, leading to a kernel crash (availability-only DoS). Affected systems are x86 hosts using Intel VT-d in scalable mode with PCI(e) devices that expose a dma_alias_mask, and the bug is reachable only when intel_pasid_setup_sm_context() fails partway through programming multiple RIDs during device probe or hot-plug. No public exploit code or CISA KEV entry was identified at time of analysis; exploitation requires high privileges (CVSS PR:H) and the assessed impact is availability-only.
The Linux kernel's drm/xe Intel GPU driver mis-computes the end of usable VRAM by rounding the flat CCS compression-storage base upward instead of downward, so a small tail of memory that belongs to the GPU's compression hardware is handed to the normal VRAM allocator as free. On affected Intel Xe hardware whose scaled flat CCS base is not 128 KiB aligned - for example a Battlemage G21 with 16 GiB, where the raw base 0x3fafff800 sits just 2 KiB below an aligned boundary - the allocator can place live kernel structures on that page, and the compression hardware then overwrites them at boot with no page-table entry, buffer object or GPU submission required, producing deterministic corruption and, in the reported case, a persistent black screen with gdm restarting in a loop. The independent assessment rates real-world risk much lower than the vendor CVSS of 7.8: exploitation is not attacker-triggered, depends entirely on unlucky hardware geometry, and no public exploit code has been identified at time of analysis, so this is best treated as a reliability/correctness defect with local integrity and availability consequences rather than a remotely reachable memory-corruption bug.
Heap out-of-bounds write in the theopolis uefi-firmware-parser Python package (versions prior to 1.14) lets a crafted Tiano/EFI-compressed firmware image corrupt heap memory when the file is parsed. The bundled native Tiano decompressor's ReadCLen() in Decompress.c reads a 9-bit length (up to 511, plus a run-length path allowing up to 531 writes) into the 510-element Sd->mCLen array without an Index < NC bound, producing a deterministic crash and potential code execution in the parsing process. No public exploit identified at time of analysis; the flaw is reached through the normal CompressedSection.process() parsing path, so any tool or service that ingests untrusted firmware with this library is at risk.
Stack out-of-bounds write in the theopolis uefi-firmware-parser Python library (versions prior to 1.14) lets a maliciously crafted Tiano/EFI-compressed firmware blob corrupt the parser's stack when it is decompressed. The bundled native Tiano decompressor's MakeTable() fails to validate Huffman bit-length values, so bit lengths above 16 overflow the stack-allocated Count[17] array and adjacent decode tables, deterministically crashing the parsing process and potentially allowing code execution in that process depending on build hardening. No public exploit identified at time of analysis; the issue was fixed in 1.14 by porting the upstream EDK2 hardening.
Heap buffer overflow in the Linux kernel's Intel THC HID QuickSPI driver allows a local low-privileged user to corrupt kernel memory via the hidraw interface. The driver's write_cmd_to_txdma() function performs an unbounded memcpy from a caller-supplied HID report into a device-descriptor-derived heap buffer of only a few hundred bytes, while the HID core permits reports up to 16,384 bytes through SET_REPORT/SET_FEATURE ioctls - a size mismatch that lets an attacker overflow the buffer with attacker-controlled length and content, enabling potential local privilege escalation to root. Vendor-released patches are available in Linux 7.2.4, 7.3-rc1, and 6.18.50; no public exploit or active exploitation has been identified at time of analysis.
Buffer overflow in the Linux kernel's Intel Touch Host Controller QuickSPI HID driver allows a local user with hidraw device access to corrupt kernel memory using device-controlled content. The function `quickspi_get_report()` copies the full device-supplied response length into the caller's buffer without checking the caller-provided size bound, so a touch controller returning more bytes than allocated overflows the kernel buffer. No public exploit exists (EPSS 0.17%, no KEV), but the sibling intel-quicki2c driver already carried the correct fix, confirming the root cause is a missing bounds-check port.
Symlink-based file clobbering in the Linux kernel's intel-speed-select daemon allows a local low-privileged user to redirect root-process writes to an attacker-chosen file by pre-positioning a symlink at the daemon's fixed /tmp pidfile path. Affected systems are those running Linux 5.18 through unpatched 6.x and 7.x branches on Intel Speed Select Technology hardware with the daemon active. No public exploit is identified at time of analysis and EPSS is low (0.17%, 7th percentile), but the attack is mechanically simple and requires only a local shell account.
Incorrect TLB flush address targeting in the Linux kernel's zap_pte_range memory management function exposes systems running kernel versions prior to 7.1.9 and 7.2 to local privilege escalation and information disclosure, particularly on AMD systems with EFER.TCE enabled and Intel systems using INVPCID. A low-privileged local attacker can exploit a race where the kernel flushes the wrong virtual address after freeing a page table, leaving stale CPU paging-structure-cache entries that can be speculatively accessed or cause the freed table to be reused with potentially attacker-controlled data. No public exploit code or active exploitation (CISA KEV) has been confirmed at time of analysis, and the 0.20% EPSS score reflects the complexity of reliable exploitation.
Server-side request forgery and local file read in the OpenSearch Security Analytics plugin exposes authenticated users with low privileges as a vector for internal network reconnaissance and credential theft. The flaw resides in the threat intelligence feed parser, which fails to validate URL parameters submitted to the threat intel source configuration endpoint, allowing a crafted request to redirect server-side HTTP fetches to internal resources - including cloud metadata endpoints. Patch is confirmed available per Amazon's security bulletin AWS-2026-079; no public exploit code has been identified at time of analysis.
Kernel-mode stack overflow in Intel PROSet/Wireless WiFi Software for Windows allows adjacent unauthenticated attackers to crash affected systems, resulting in a full system denial of service. The flaw resides in Ring 0 (kernel privilege level) WiFi driver code, meaning a successful exploit triggers a kernel panic or Blue Screen of Death rather than a user-space crash. No public exploit or CISA KEV listing has been identified at time of analysis, and no exact patched version is confirmed in the available reference data - the Intel advisory INTEL-SA-01468 should be consulted directly.
Kernel-mode denial of service in Intel PROSet/Wireless WiFi Software for Windows allows an adjacent unauthenticated attacker to crash the target system by triggering an improper buffer restriction in the Ring 0 (kernel-level) WiFi driver component. The vulnerability carries a CVSS 4.0 score of 8.3, requires no authentication or user interaction, and is confined to adjacent-network attackers. Intel has acknowledged the issue via security advisory INTEL-SA-01468; no public exploit code exists and no CISA KEV listing has been identified at time of analysis.
Privilege escalation in the Alias Checking Trusted Module (ACTM) firmware for certain Intel Xeon processors allows a local privileged attacker to escalate to System Management Mode (SMM) execution, achieving high confidentiality and integrity impact across both the directly compromised system and subsequent systems such as co-hosted hypervisors or tenant workloads. The attack requires high-complexity local technique combined with pre-existing privileged user access, placing it firmly in the advanced persistent threat actor category. No public exploit has been identified at time of analysis, and Intel has published advisory INTEL-SA-01439 to address this firmware flaw.
Privilege escalation in Intel PROSet/Wireless WiFi Software for Windows allows local unprivileged code operating within the Ring 2 privileged process boundary to elevate access rights due to improper privilege management (CWE-269), yielding high availability impact and limited confidentiality and integrity exposure on both the vulnerable and subsequent systems. The attack is constrained to local access and requires high complexity, but no prior authentication or user interaction is needed from the attacker. Intel has published advisory INTEL-SA-01468 to address this flaw; no public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
Improper authentication (CWE-287) in Intel's Trust Domain Extensions (TDX) module allows a Ring-0 system software adversary with high privileges to breach Trust Domain isolation boundaries, enabling information disclosure and privilege escalation. Affects select Intel platforms running TDX with a high-complexity, locally-executed attack path - no user interaction required. No public exploit identified at time of analysis, but the confidential-computing trust model is fundamentally undermined if exploited: an adversary with hypervisor-level access could read or modify memory intended to be protected from exactly that privilege tier.
Denial of service in Intel PROSet/Wireless WiFi Software for Windows stems from a null pointer dereference (CWE-476) in the Ring 2 device driver layer, allowing an adjacent unauthenticated attacker to crash the affected system with no user interaction required. The CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:N/UI:N/VA:H) confirms low-complexity exploitation from the same network segment, resulting in high availability impact to the vulnerable system and residual low availability impact to subsequent systems. No public exploit code or CISA KEV entry has been identified at time of analysis, though the absence of authentication and interaction requirements makes this trivially triggerable by any adjacent network adversary.
Denial of service in Intel PROSet/Wireless WiFi Software for Windows stems from improper buffer restrictions (CWE-119) in the Ring 2 device driver layer, exploitable by an adjacent network attacker without authentication or user interaction. An attacker within Wi-Fi range or on the same network segment can trigger a driver-level crash by sending crafted wireless input, resulting in high availability impact on the target system and low availability impact on subsequent systems, with no confidentiality or integrity consequences. No public exploit code has been identified and this CVE is not listed in the CISA KEV catalog at time of analysis.
Privilege escalation in Intel PROSet/Wireless WiFi Software for Windows exposes local systems to code execution by unprivileged attackers via a Ring 2 (device driver layer) improper access control flaw. Any local process with no privileges required and no user interaction can leverage the driver's failure to enforce access boundaries to achieve local code execution, with follow-on high confidentiality impact on the broader system - consistent with a kernel-level scope change. No public exploit identified at time of analysis, and no CISA KEV listing; however, the low complexity and zero-privilege requirement make this a credible post-compromise escalation vector for threat actors with any form of local code execution already established.
Null pointer dereference in Intel PROSet/Wireless WiFi Software for Windows at the Ring 2 device driver layer enables denial of service by an unauthenticated adjacent-network attacker. Disclosed by Intel in advisory INTEL-SA-01422, the flaw affects all currently indexed versions of the software and can be triggered at low complexity with no user interaction or special attack prerequisites. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Out-of-bounds read in the kernel-mode (Ring 0) component of Intel PROSet/Wireless WiFi Software for Windows enables a denial-of-service condition against affected Windows hosts. An unauthenticated attacker with adjacent network access and the ability to satisfy specific attack requirements can trigger a kernel-level crash, resulting in high availability impact to both the vulnerable system and any subsequent system processes. No public exploit code has been identified at time of analysis, and this CVE has not been listed in the CISA Known Exploited Vulnerabilities catalog.
Denial of service in Intel PROSet/Wireless WiFi Software affects the Ring 2 device driver layer, where an improper conditions check (CWE-754) can be triggered by an adjacent, unauthenticated attacker with no user interaction required. The vulnerability collapses wireless availability on the affected host and, per the CVSS 4.0 vector, cascades to subsequent system availability as well, meaning dependent network-connected services may also be disrupted. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Out-of-bounds read in Intel PROSet/Wireless WiFi Software at the Ring 2 device driver layer allows adjacent network attackers without authentication to escalate privileges on affected Windows systems. The flaw, tracked under CWE-125, can be triggered by a low-complexity attack from the same WiFi segment or Layer 2 broadcast domain, requiring no user interaction, and yields High availability impact alongside Low confidentiality and integrity exposure. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV, but the unauthenticated adjacent attack surface is meaningful for enterprise mobile workforces on untrusted networks.
Denial of service in Intel PROSet/Wireless WiFi Software device drivers (Ring 2) allows an unauthenticated adjacent-network attacker to crash or disable the wireless subsystem on affected systems. The flaw stems from an improper conditions check (CWE-754) within the WiFi driver stack, meaning edge-case or malformed network input is not handled safely, leading to complete availability loss of the vulnerable system. No public exploit code and no CISA KEV listing have been identified at time of analysis, though the low-complexity, zero-privilege attack vector makes this straightforward to trigger from WiFi range.
Out-of-bounds write in Intel PROSet/Wireless WiFi Software for Windows device drivers (Ring 2) allows adjacent network attackers to trigger a denial of service condition without authentication or user interaction. Unauthenticated attackers on the same network segment can exploit this CWE-787 buffer overflow flaw with low complexity, causing high availability impact to the affected Windows system and low residual availability impact on subsequent systems. No public exploit code and no CISA KEV listing exist at time of analysis.
Improper access control in Intel PROSet/Wireless WiFi Software device drivers (Ring 2) allows a local unprivileged process to cause a denial of service affecting both the wireless subsystem and, to a lesser extent, downstream system integrity. Affected systems running Intel wireless drivers are exposed to any unprivileged local code - no authentication, no elevated privileges, and no user interaction are required. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in the CISA KEV catalog.
Denial-of-service in Intel PROSet/Wireless WiFi Software for Windows (Ring 2 device driver layer) allows an unauthenticated adjacent-network attacker to crash or disable the wireless driver with no user interaction. The flaw stems from an improper conditions check (CWE-754) in the driver, yielding complete loss of wireless availability on the affected system and minor downstream availability impact on subsequently connected systems. No public exploit or CISA KEV listing exists at time of analysis, and Intel has published an advisory at INTEL-SA-01422.
Intel PROSet/Wireless WiFi Software for Windows contains a null pointer dereference in Ring 0 (kernel space) that an adjacent, unauthenticated attacker can exploit to crash the target system, resulting in a denial of service. The flaw resides in the WiFi kernel driver, meaning a successful trigger causes a kernel panic (BSOD on Windows) with high availability impact on both the vulnerable component and the broader system. No public exploit code has been identified at time of analysis, and no KEV listing exists, but the adjacent-network attack vector and zero-privilege requirement make this relevant for any environment where untrusted parties share a wireless segment with Intel WiFi-equipped Windows endpoints.
Improper access control within Ring 3 (user application space) of Intel processors permits privilege escalation from authenticated local user-level access to higher system privilege levels, with high confidentiality and integrity impact on the vulnerable system. Exploitation demands local access, low-privilege authentication, high attack complexity, and specialized internal knowledge of Intel processor microarchitecture internals - substantially narrowing the realistic attacker population. No public exploit code has been identified and no CISA KEV listing exists at time of analysis, consistent with a threat relevant primarily to sophisticated, targeted adversaries.
Denial of service via improper input validation in Intel Active Management Technology (AMT) and Intel Standard Manageability firmware allows unauthenticated network-adjacent attackers to disrupt the out-of-band management interface. The CVSS 4.0 AT:P designation confirms that specific prerequisites - namely AMT being provisioned and network-accessible - must independently exist before exploitation is possible. No public exploit has been identified at time of analysis, and Intel has disclosed the issue under advisory INTEL-SA-01427.
Protection mechanism failure in Intel Data Center Attestation Primitives (Intel DCAP) enables unauthenticated network-based attackers with specialized internal knowledge to undermine the integrity of the attestation system and expose confidential data from downstream systems relying on SGX enclave verification. The vulnerability (CWE-693) is particularly impactful in confidential computing environments where DCAP serves as the trust anchor for SGX workload isolation. No public exploit has been identified at time of analysis, and Intel has published advisory INTEL-SA-01449 addressing this issue.
Out-of-bounds kernel memory access in the Linux drm/xe Intel GPU driver allows a local low-privileged user to read sensitive kernel memory, cause a kernel panic, or potentially corrupt kernel state. The flaw exists in the BO (buffer object) prefetch path of the Intel Xe GPU subsystem, where DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC (value -1) is incorrectly used as an array index into region_to_mem_type[], accessing memory before the array's base address. Discovered via AI-assisted static analysis confirmed by Intel Product Security; no public exploit or CISA KEV listing identified at time of analysis.
Buffer overflow in the Intel i915 HDCP subsystem of the Linux kernel allows a local, low-privileged user to corrupt kernel memory with potential privilege escalation to full system compromise. The bounds check on the `data->streams[]` array write executes after the overrun has already occurred, meaning any caller who can trigger this code path can write past the array boundary before the kernel detects the violation. Discovered via AI-assisted static analysis and confirmed by Intel Product Security; no public exploit exists and EPSS probability is 0.18%, indicating no observed exploitation at time of analysis.
Out-of-bounds bitmap write in the Linux kernel's Intel ICE SR-IOV driver allows a malicious Virtual Function guest to crash the host kernel or potentially escalate privileges to the host. The vulnerable function ice_parser_profile_init unconditionally passes caller-controlled ptype values from VIRTCHNL_OP_ADD_RSS_CFG into set_bit() against a statically sized 1024-bit bitmap, permitting a value such as 0xffff to write beyond the bitmap boundary and trigger a kernel NULL pointer dereference. No public exploit code has been identified and EPSS exploitation probability is low at 0.18%, but the CVSS 8.8 score and confirmed crash reproducibility signal real urgency for SR-IOV multi-tenant environments where stable-branch patches are already available.
Unbounded retry loops in BC-FJA's JNI native entropy layer cause calling threads to hang indefinitely when Intel RDSEED or RDRAND instructions persistently fail, producing a non-interruptible thread-level denial of service in any Java FIPS application backed by bc-fips 2.1.x before 2.1.3. The affected JNI seeding routine re-issues the CPU entropy instruction without any iteration limit whenever the carry flag signals failure - a condition reproducible by hardware entropy source faults, DRBG exhaustion under heavy multi-core contention, or hypervisors that do not forward these Intel instructions to guest VMs. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the conditions are routinely present in virtualized environments where hypervisors commonly withhold RDRAND/RDSEED forwarding, making this a realistic operational risk for enterprise Java FIPS deployments in cloud or VM-based infrastructure.
Remote denial of service in Thumbor's convolution filter (versions <= 7.7.7) allows an attacker to crash the Thumbor worker process with a single crafted HTTP request by passing columns=0 to the filters:convolution() URL parameter. The Python-layer input validation accepts zero via an overly permissive regex (PositiveNumber matches '0'), which propagates to a C extension that performs integer division by zero, triggering SIGFPE and killing the process on x86_64 Linux and macOS Intel. No public exploit identified at time of analysis per KEV, but a fully functional proof-of-concept is documented in the vendor's own GHSA advisory, making exploitation trivially reproducible.
Denial of service in the Linux kernel's Intel iwlwifi 'mld' Wi-Fi driver allows a firmware crash on Intel BE201/Wi-Fi 7 adapters to spiral into sustained resource exhaustion. Because iwl_mld_tx_from_txq() failed to check the in_hw_restart flag, TX frames kept being dequeued and pushed to dead firmware, each returning -EIO and being freed in a tight loop that burns CPU and churns skb allocations, causing slab fragmentation and memory pressure. There is no public exploit identified at time of analysis, EPSS risk is low (0.16%, 6th percentile), and the issue is not on CISA KEV; it is a reliability/availability bug that manifests under real load, not an attacker-driven remote exploit.
Local privilege-impacting memory corruption in the Linux kernel's Intel ice network driver allows a double-free of a transmit buffer's skb when the TX offload paths fail. When ice_tso() or ice_tx_csum() return an error, ice_xmit_frame_ring() frees the skb but leaves the 'first' tx_buf still marked ICE_TX_BUF_SKB, so a later ice_clean_tx_ring() during interface teardown frees the same skb a second time. Carries a CVSS 3.1 base of 7.8 (AV:L/PR:L), but with a low EPSS of 0.15% (5th percentile), no KEV listing, and no public exploit identified at time of analysis.
Race condition in the Linux kernel's Intel VT-d IOMMU driver allows a local low-privileged attacker to trigger inconsistent PASID table state during domain replacement, potentially producing spurious IOMMU faults and unpredictable DMA behavior with cross-scope impact. The flaw stems from non-atomic updates to 512-bit PASID entries while the Present bit is set, and no public exploit identified at time of analysis despite a high CVSS score driven by the scope-changed local attack surface.
Kernel memory corruption in the Linux iWARP Connection Manager (RDMA/iwcm) subsystem can crash systems running RDMA workloads on iWARP-capable hardware such as Intel E830 adapters. The bug, introduced by commit e1168f0 ('RDMA/iwcm: Simplify cm_event_handler()'), causes workqueue list corruption when iwcm_work items from a free list are reused while still queued, triggering a kernel BUG and panic. No public exploit identified at time of analysis and EPSS exploitation probability is very low (0.02%, 5th percentile), despite a CVSS base score of 9.8.
Out-of-bounds array access in the Linux kernel's Intel Discrete Graphics MTD driver (mtd_intel_dg.c) lets a local actor trigger kernel memory corruption when the driver enumerates NVM regions before nregions is initialized. The flaw, caught by UBSAN as an array-index-out-of-bounds at line 750, affects systems running kernel 6.17 through the pre-patch 6.18/6.19 series with Intel discrete graphics hardware. No public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.02%, 4th percentile).
Race condition in Linux kernel Intel VT-d IOMMU driver (iommu/vt-d) allows torn reads of Scalable Mode PASID table entries during teardown, producing unpredictable behavior or spurious faults on systems with Intel VT-d enabled. The flaw stems from zeroing the entire 64-byte PASID entry while the Present bit is still set, violating the VT-d spec's invalidation guidance. No public exploit identified at time of analysis, and EPSS is very low (0.02%), but a vendor patch is available across multiple stable branches.
Denial of service in the Linux kernel's EFI unaccepted-memory handling allows a boot-time kernel panic on confidential-computing guests, affecting kernels from 6.6 through the 6.19/7.0 development line. The reserve_unaccepted() routine miscalculates the memblock reservation size when the unaccepted memory table is not page-aligned, leaving the table's tail unreserved so it can be overwritten or rendered inaccessible, triggering a panic in accept_memory(). It is observed on Intel TDX VMs with larger memory sizes (e.g. >64GB); there is no public exploit identified at time of analysis and EPSS is negligible (0.02%).
Traffic Management Microkernel (TMM) crashes in F5 BIG-IP Virtual Edition and hardware platforms when SSL profiles are configured without hardware crypto acceleration, allowing remote unauthenticated attackers to cause denial of service via undisclosed traffic patterns. CVSS 7.5 (High) with network attack vector and no prerequisites. EPSS data not provided, no CISA KEV listing identified, indicating theoretical rather than observed exploitation. Vendor patch available per F5 advisory K000158082.
Local privilege escalation in Intel QuickAssist Technology (QAT) software drivers for Windows before version 1.13 lets an authenticated low-privileged user elevate to higher privileges through improper input validation in a Ring 3 user-application code path. The flaw was reported by Intel PSIRT (INTEL-SA-01387) and carries a CVSS 4.0 base of 8.5, but there is no public exploit identified at time of analysis and EPSS is a low 0.03% (8th percentile). SSVC scores exploitation as none and not automatable, consistent with a driver bug that requires prior local, authenticated access.
Local privilege escalation in Intel QuickAssist Technology (QAT) software drivers for Windows before version 1.13 lets an authenticated, unprivileged local user escalate to higher privileges via an out-of-bounds write (CWE-787) in Ring 3 user-application code. The flaw carries a CVSS 4.0 base score of 8.5 with total technical impact but is not known to be exploited - CISA's SSVC framework rates exploitation as 'none' and EPSS is negligible at 0.01% (3rd percentile), with no public exploit identified at time of analysis.
Improper access control in all versions of Intel Vision software allows a remote, unauthenticated attacker to trigger denial of service and, under low-complexity conditions, achieve remote code execution against the Ring 3 user-application layer. The CVSS 4.0 base score of 8.8 reflects high confidentiality impact with lesser integrity and availability effects; there is no public exploit identified at time of analysis, and EPSS is low at 0.20% (42nd percentile). Intel published advisory SA-01457 and CISA's SSVC framework rates exploitation as none but technical impact as total.
Local privilege-driven data corruption in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 allows a privileged local adversary to trigger an out-of-bounds write (CWE-787) in a Ring 1 device driver, causing denial of service and integrity loss. The flaw affects the vulnerable system's integrity and availability (both High) with no confidentiality impact, and carries a CVSS 4.0 base score of 8.3. There is no public exploit identified at time of analysis, and the EPSS probability is negligible at 0.01%.
Local privilege escalation in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 lets a privileged local user trigger a Ring 1 device-driver buffer overflow to execute arbitrary code and take total control of the host. The flaw carries a CVSS 4.0 base score of 9.3 with high confidentiality, integrity and availability impact on both the vulnerable and subsequent systems. There is no public exploit identified at time of analysis, and the EPSS score is negligible at 0.01% (3rd percentile), consistent with the SSVC verdict of no known exploitation.
Local privilege-abusing denial of service and information disclosure in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 lets a privileged local user trigger an out-of-bounds read (CWE-125) in the Ring 1 device-driver layer, potentially crashing the host and exposing adjacent memory. The flaw carries a CVSS 4.0 base score of 8.3 driven by high confidentiality and availability impact plus a scope change into subsequent systems. There is no public exploit identified at time of analysis, EPSS is negligible (0.01%), and CISA SSVC rates exploitation as 'none' and non-automatable.
Local privilege escalation in Intel QuickAssist Adapter 8960 software before version 1.13 allows an authenticated, low-privileged user to abuse an untrusted pointer dereference in a Ring 3 user-application component to gain elevated privileges on the host. The flaw yields total impact (high confidentiality, integrity, and availability) on the affected system and carries a CVSS 4.0 base score of 8.5. There is no public exploit identified at time of analysis, and EPSS rates near-term exploitation probability at just 0.01%.
Integer overflow in Linux kernel's i915 graphics driver corrupts memory mapping for DRM/GEM shmem objects larger than 4GB, causing kernel warnings, potential crashes, and incorrect memory access when Intel graphics hardware processes large buffer objects. The vulnerability manifests when scatterlist length fields overflow during folio page allocation, leading to premature termination of backing page iteration. Patch available across multiple stable kernel branches (6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0) per upstream commits. EPSS score of 0.02% (5th percentile) indicates low observed exploitation probability, and no public exploit code or CISA KEV listing exists at time of analysis.
Stack buffer overflow in Sandboxie-Plus SbieSvc proxy service enables SYSTEM privilege escalation from sandboxed processes, including Security Hardened Sandboxes. Attackers chain an information disclosure (returning up to 32KB uninitialized stack memory with ASLR/stack cookie bypass) with an unbounded memcpy overflow in the GetRawInputDeviceInfoSlave IPC handler. Intel CET shadow stacks block ROP exploitation but not the information leak itself. Vendor-released patch available in version 1.17.3. No public exploit identified at time of analysis, but attack complexity is rated high (AC:H) with low privilege requirements (PR:L), making this viable for motivated attackers targeting sandbox environments.
Use-after-free in Linux kernel Bluetooth Intel driver enables local privilege escalation to kernel code execution. Affects Linux kernel 4.3 through 7.0-rc5, with patches available in versions 6.6.131, 6.12.80, 6.18.21, 6.19.11, and 7.0. Exploitation requires local authenticated access with low privileges (CVSS PR:L). EPSS score of 0.02% (5th percentile) indicates low probability of widespread exploitation. No public exploit code or active exploitation confirmed at time of analysis, though technical details in CVE description provide implementation roadmap.
Attested TLS relay attacks in Cocos AI confidential computing system versions 0.4.0 through 0.8.2 enable attackers to impersonate genuine TEE-protected services on AMD SEV-SNP and Intel TDX platforms by extracting ephemeral TLS private keys and redirecting authenticated sessions. The architectural flaw allows an attacker with physical access or side-channel capabilities to relay attestation evidence to a different endpoint, breaking the authentication binding between the TEE and the client. No vendor-released patch is available; the vulnerability affects a specialized confidential computing platform with low EPSS probability (formal EPSS score not provided in input) and no public exploit identified at time of analysis, though formal ProVerif verification confirms the attack feasibility.
This vulnerability in Intel EPT (Extended Page Tables) paging code within Xen allows information disclosure through a use-after-free condition in cached EPT state management. When paging structures are freed before cached EPT state is flushed, stale entries can persist in the EPT cache pointing to memory ranges outside the guest's intended ownership, enabling unauthorized memory access. Xen across multiple versions is affected, with Ubuntu tracking the issue at medium priority across 7 releases and Debian across 7 releases, making this a widespread concern for virtualization infrastructure.
A cookie management issue was addressed with improved state management. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and no vendor patch available.
Arbitrary code execution in Apple Safari, iOS/iPadOS, macOS Sequoia, and visionOS occurs when processing maliciously crafted web content, with Apple confirming active exploitation on Intel-based Mac systems. The flaw is confirmed actively exploited (CISA KEV) and carries a CVSS 8.8 score requiring only user interaction (visiting a malicious page) to achieve remote code execution. EPSS at 1.55% (81st percentile) is moderate but the KEV listing signals real-world targeted abuse against Apple's WebKit-based browsing stack.
Apache Log4j2 contains a critical JNDI injection vulnerability known as 'Log4Shell' that allows unauthenticated remote code execution through crafted log messages, affecting virtually every Java application on Earth and triggering the largest vulnerability remediation effort in history.
A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels,. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. Public exploit code available.
Local privilege escalation to SYSTEM in Intel Ethernet diagnostics driver (IQVW32.sys/IQVW64.sys versions before 1.3.1.0) allows authenticated Windows users to execute arbitrary code with kernel privileges via crafted IOCTL calls to device driver interfaces. CISA confirms active exploitation in the wild (KEV-listed). Multiple public proof-of-concept exploits demonstrate exploitability across four IOCTL handlers (0x80862013, 0x8086200B, 0x8086200F, 0x80862007). With 4.99% EPSS probability (90th percentile) and confirmed real-world abuse, this represents a critical risk for systems with Intel network adapters where the diagnostic driver remains installed and unpatched.
An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs: Intel Active Management Technology (AMT) and Intel Standard Manageability (ISM). Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable SDK for UPnP Devices (aka libupnp, formerly the Intel SDK for UPnP devices). Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and EPSS exploitation probability 88.6%.
The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and other products; Oracle Solaris 11 and earlier; illumos before r13724; Joyent. Rated high severity (CVSS 7.2), this vulnerability is low attack complexity. Public exploit code available and EPSS exploitation probability 88.0%.
Host denial-of-service in illumos bhyve allows a privileged guest user to panic the host by executing a REP-prefixed MOVS or STOS instruction targeting kernel-emulated MMIO regions such as the local APIC. The flaw has existed since 2020 and affects illumos-gate and OmniOS builds prior to commit 696ecf8d, stemming from a failure to clear the VIES_REPEAT flag that leads to a VERIFY assertion in vie_advance_pc(). Publicly available exploit code exists, but no active exploitation has been confirmed.
Denuvo Anti-Tamper (through 2026-03-04) can be bypassed by locally authenticated administrators with kernel-level privileges who load a hypervisor driver that intercepts CPUID instructions and spoofs hypervisor-absence results, defeating the anti-tamper check on AMD (SimpleSvm.sys) and Intel (hyperkd.sys, hyperhv.dll) platforms. The vulnerability has a CVSS score of 1.9 (AV:L/AC:H/PR:H) and only affects the integrity of the DRM check on the attacker's own system, with no third-party victim or escalation. No public exploit identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Clean up the bus when fetching ML caps fails snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope.
An unbalanced module reference count in the Linux kernel's Intel AVS (Audio, Voice, Speech) ASoC audio driver lets a local, authenticated user leak a module reference every time a specific error path in the driver-open routine is hit, which over repeated triggering can leave the driver module permanently pinned and degrade availability (module unload/reload fails). Only systems running a vulnerable kernel build with the Intel AVS DSP audio stack present and loaded are exposed, and our assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, a low-to-moderate priority local availability issue rather than a widespread emergency. EPSS is 0.17% (5th percentile), the issue is not in CISA KEV, and no public exploit identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53 and 7.2.7 plus mainline 7.3-rc3.
Out-of-bounds read in the Linux kernel's Intel AVS ASoC audio driver can crash the kernel when a local user with low privileges causes an oversized module config ID from a DSP topology binary to index the init_configs array. The flaw is limited to local, low-privilege access on systems with Intel AVS audio hardware and the relevant driver loaded; it is not remotely reachable and, per the assessed vector, has no confidentiality or integrity impact. EPSS is low (0.17%, 5th percentile), no public exploit code has been identified at time of analysis, and vendor fixes are available in Linux 6.18.53, 7.2.7, and 7.3-rc3 or corresponding stable backports.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Prevent drain_pebs() reentry The PEBS buffer is shared by all events on a CPU, so drain_pebs() must not be reentered. If so, one instance may observe stale buffer state and potentially access out-of-bound memory. Most invocations happen in NMI context, which naturally prevents reentry. However, drain_pebs() is also reachable from process context via intel_pmu_drain_pebs_buffer(). In those paths, the PMU is often already disabled, but not guaranteed. For example, __intel_pmu_pebs_disable() only disables the target counter, so other active counters can still raise a PMI and interrupt an in-flight drain_pebs(). Here is an example, __perf_addr_filters_adjust() perf_event_stop() __perf_event_stop() x86_pmu_stop() (event->pmu->stop) intel_pmu_disable_event() intel_pmu_pebs_disable() __intel_pmu_pebs_disable() intel_pmu_drain_large_pebs() intel_pmu_drain_pebs_buffer() Introduce __intel_pmu_quiesce() and __intel_pmu_resume() helpers and use them in intel_pmu_drain_large_pebs() to disable the full PMU around the intel_pmu_drain_pebs_buffer() call, preventing reentry. Also add a warning in intel_pmu_drain_pebs_buffer() when the full PMU is not disabled.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured.
Local information disclosure in Dell Command | Intel vPro Out of Band versions prior to 4.7.2 lets an authenticated, low-privileged user on a Windows host read data that should have been restricted, because the product ships files, directories, registry keys, or objects with overly permissive default access controls (CWE-276). Per the vendor's own advisory the impact is limited to confidentiality - no integrity or availability effect - and the vector requires local access plus a valid low-privilege account (AV:L/PR:L/UI:N), which is why it scores a moderate 5.5. No KEV listing or public exploit code was identified at time of analysis, and no public exploit has been identified; real-world risk is confined to hosts where an attacker already has a foothold, so this is routine patch-cycle work rather than an emergency.
An out-of-bounds write of up to 895 bytes into static (.bss) memory can be triggered in Zephyr RTOS's Intel SEDI IPM driver (drivers/ipm/ipm_sedi.c) when the peer processor sets a doorbell payload length larger than the 128-byte incoming_data_buf. The vulnerable path is reachable when an application has registered an IPM receive callback via ipm_register_callback(), the driver's normal mode of use, and requires a local, highly privileged attacker (CVSS PR:H) with host-side ISH driver-level or raw BAR access to the device's memory-mapped register window, plus a production image built without CONFIG_DEBUG so the HAL's DBG_CHECK length guard is compiled away. The result is kernel data-structure corruption and a crash primitive - the overflow clobbers the driver context's k_sem and k_mutex and adjacent static data - but the flaw is platform-specific and locally scoped, so it is a moderate, defense-in-depth-relevant issue rather than an urgent internet-facing emergency; no public exploit identified at time of analysis, and an upstream fix commit is available.
In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix recursive locking during device registration i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: disconnect on CSA to channel 0 The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.
In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix async notifier cleanup leak on parse error isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start() In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed.
In the Linux kernel, the following vulnerability has been resolved: Revert "PCI/MSI: Unmap MSI-X region on error" This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202. Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails. When msix_setup_interrupts() fails, the call chain is: msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap: void pci_free_msi_irqs(struct pci_dev *dev) { pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) { iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } } So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer. This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh: WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 confirms iounmap() is called with NULL. Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup.
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)
In the Linux kernel, the following vulnerability has been resolved: platform/x86/intel/tpmi: use cleanup helpers in mem_write() In mem_write(), the temporary array returned by parse_int_array_user() must be released on all exit paths. Convert the array variable to use cleanup.h scope-based cleanup so it is freed automatically on return. This also moves the array declaration next to parse_int_array_user() as required by cleanup.h usage guidelines.
Kernel information disclosure and local denial of service affect Zephyr RTOS on Intel ALH-equipped hardware through an unvalidated stream_id parameter in the Intel ALH digital-audio-interface driver. A local user-mode thread holding explicit ALH device-object access can invoke the dai_get_properties_copy() syscall with an arbitrary stream_id, triggering an out-of-bounds read from the fixed 64-entry alh_handshake_map[] array and leaking one byte of kernel memory per call, along with a computed FIFO register address that can expose kernel address-space layout. No public exploit has been identified at time of analysis; exploitation is constrained to systems built with CONFIG_USERSPACE and where device-object access has been deliberately granted to untrusted threads.
Transient execution information disclosure in Intel processors allows a Ring 0 (kernel or hypervisor level) adversary to leak sensitive data across security boundaries into a subsequent system context. The flaw stems from incorrect data forwarding during speculative execution, a class of hardware-level side-channel vulnerability similar to Spectre-class attacks, requiring local access with high privileges and high attack complexity. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; however, successful exploitation enables high-confidentiality-impact cross-boundary data exposure, threatening hypervisor isolation guarantees critical in virtualized and cloud environments.
Attestation bypass in PrivaSys Enclave OS Mini before wasm-v0.40.0 allows an attacker who already possesses a valid enclave RA-TLS private key to relay a genuine SGX/TDX attestation quote onto a TLS connection the attacker terminates, so a relying party accepts an attacker-controlled channel as the attested enclave. The root cause is a missing TLS-session channel binding (CWE-346): in challenge-response mode the quote's ReportData folded only the certificate public-key hash and the client nonce, so nothing in the quote committed to the specific handshake, making a relayed quote valid on any connection. CVSS 4.0 rates this 9.1 (network reachable, unauthenticated per PR:N, no user interaction, high confidentiality and integrity impact), but the independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and the AT:P metric correctly temper it: exploitation presupposes a prior enclave key compromise and a challenge-mode deployment, and no public exploit has been identified at time of analysis.
Incorrect DMA mmap handling in the Linux kernel's IB/hfi1 Omni-Path driver (PIO_CRED case) lets a local, authenticated user with access to the HFI character device crash the kernel with a corrupted page-table oops or, once only the offset arithmetic is corrected, permanently stall send-PIO transfers. Kernels from 6.3 onward that include the hfi1 driver are affected, but the fault is intermittent-it appears only when the hardware send-context index reaches 64 or 128-and requires Intel Omni-Path 100 hardware plus the PSM2 path to invoke hfi1_file_mmap(). No public exploit code was identified at time of analysis, EPSS is low (0.18%, 6th percentile), and vendor-released fixes exist in 6.6.158, 6.12.112, 6.18.54, 7.2.8 and 7.3-rc4; given the local-only vector, mandatory specialized hardware and intermittency, overall risk is assessed as moderate rather than high-priority.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
Local privilege escalation in Zephyr RTOS allows an unprivileged user-mode thread that holds access to the Intel time-aware GPIO (TGPIO) device object to perform two uncontrolled 8-byte supervisor-mode writes to attacker-chosen kernel addresses via the tgpio_pin_read_ts_ec() syscall. The syscall's verification handler omitted the K_SYSCALL_MEMORY_WRITE() check that the sibling handlers in the same file already perform, converting a benign timestamp read-back into a write-what-where primitive that can corrupt kernel data structures, escalate the calling thread to supervisor privilege, or crash the system. Exposed builds are narrow: CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y must both be set, and because the affected source file failed to compile from v3.6.0 until after it was repaired past v4.4.0, the realistically exposed population is v3.5.0 builds plus downstream trees that locally patched that build breakage; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though it is rated CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Ultraviolet CoCoS through version 0.8.2 contains a session-misbinding flaw in the intra-handshake attested TLS (aTLS) verification path for Intel TDX: the verifier fails to copy the expected current-session freshness value into the TDX quote-body policy before quote validation, so any structurally valid TDX QuoteV4 Evidence is accepted without checking that its REPORT_DATA field matches the reportData expected for that session. An unauthenticated remote counterparty (CVSS vector AV:N/PR:N) that can supply or relay such a quote - acting as the attesting party or replaying a previously captured or foreign quote - can therefore cause a relying party to release application data bound to an unintended attestation context, giving high confidentiality and integrity impact. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the vendor's 9.1 score (AV:N/AC:L) slightly overstates ease of exploitation versus our assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, since a valid TDX quote and use of the affected TDX aTLS branch are prerequisites. The issue is fixed in version 0.9.0.
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.
Linux kernel's Intel VT-d IOMMU scalable-mode probe failure path can leave context entries pointing to a freed PASID table, leading to a kernel crash (availability-only DoS). Affected systems are x86 hosts using Intel VT-d in scalable mode with PCI(e) devices that expose a dma_alias_mask, and the bug is reachable only when intel_pasid_setup_sm_context() fails partway through programming multiple RIDs during device probe or hot-plug. No public exploit code or CISA KEV entry was identified at time of analysis; exploitation requires high privileges (CVSS PR:H) and the assessed impact is availability-only.
The Linux kernel's drm/xe Intel GPU driver mis-computes the end of usable VRAM by rounding the flat CCS compression-storage base upward instead of downward, so a small tail of memory that belongs to the GPU's compression hardware is handed to the normal VRAM allocator as free. On affected Intel Xe hardware whose scaled flat CCS base is not 128 KiB aligned - for example a Battlemage G21 with 16 GiB, where the raw base 0x3fafff800 sits just 2 KiB below an aligned boundary - the allocator can place live kernel structures on that page, and the compression hardware then overwrites them at boot with no page-table entry, buffer object or GPU submission required, producing deterministic corruption and, in the reported case, a persistent black screen with gdm restarting in a loop. The independent assessment rates real-world risk much lower than the vendor CVSS of 7.8: exploitation is not attacker-triggered, depends entirely on unlucky hardware geometry, and no public exploit code has been identified at time of analysis, so this is best treated as a reliability/correctness defect with local integrity and availability consequences rather than a remotely reachable memory-corruption bug.
Heap out-of-bounds write in the theopolis uefi-firmware-parser Python package (versions prior to 1.14) lets a crafted Tiano/EFI-compressed firmware image corrupt heap memory when the file is parsed. The bundled native Tiano decompressor's ReadCLen() in Decompress.c reads a 9-bit length (up to 511, plus a run-length path allowing up to 531 writes) into the 510-element Sd->mCLen array without an Index < NC bound, producing a deterministic crash and potential code execution in the parsing process. No public exploit identified at time of analysis; the flaw is reached through the normal CompressedSection.process() parsing path, so any tool or service that ingests untrusted firmware with this library is at risk.
Stack out-of-bounds write in the theopolis uefi-firmware-parser Python library (versions prior to 1.14) lets a maliciously crafted Tiano/EFI-compressed firmware blob corrupt the parser's stack when it is decompressed. The bundled native Tiano decompressor's MakeTable() fails to validate Huffman bit-length values, so bit lengths above 16 overflow the stack-allocated Count[17] array and adjacent decode tables, deterministically crashing the parsing process and potentially allowing code execution in that process depending on build hardening. No public exploit identified at time of analysis; the issue was fixed in 1.14 by porting the upstream EDK2 hardening.
Heap buffer overflow in the Linux kernel's Intel THC HID QuickSPI driver allows a local low-privileged user to corrupt kernel memory via the hidraw interface. The driver's write_cmd_to_txdma() function performs an unbounded memcpy from a caller-supplied HID report into a device-descriptor-derived heap buffer of only a few hundred bytes, while the HID core permits reports up to 16,384 bytes through SET_REPORT/SET_FEATURE ioctls - a size mismatch that lets an attacker overflow the buffer with attacker-controlled length and content, enabling potential local privilege escalation to root. Vendor-released patches are available in Linux 7.2.4, 7.3-rc1, and 6.18.50; no public exploit or active exploitation has been identified at time of analysis.
Buffer overflow in the Linux kernel's Intel Touch Host Controller QuickSPI HID driver allows a local user with hidraw device access to corrupt kernel memory using device-controlled content. The function `quickspi_get_report()` copies the full device-supplied response length into the caller's buffer without checking the caller-provided size bound, so a touch controller returning more bytes than allocated overflows the kernel buffer. No public exploit exists (EPSS 0.17%, no KEV), but the sibling intel-quicki2c driver already carried the correct fix, confirming the root cause is a missing bounds-check port.
Symlink-based file clobbering in the Linux kernel's intel-speed-select daemon allows a local low-privileged user to redirect root-process writes to an attacker-chosen file by pre-positioning a symlink at the daemon's fixed /tmp pidfile path. Affected systems are those running Linux 5.18 through unpatched 6.x and 7.x branches on Intel Speed Select Technology hardware with the daemon active. No public exploit is identified at time of analysis and EPSS is low (0.17%, 7th percentile), but the attack is mechanically simple and requires only a local shell account.
Incorrect TLB flush address targeting in the Linux kernel's zap_pte_range memory management function exposes systems running kernel versions prior to 7.1.9 and 7.2 to local privilege escalation and information disclosure, particularly on AMD systems with EFER.TCE enabled and Intel systems using INVPCID. A low-privileged local attacker can exploit a race where the kernel flushes the wrong virtual address after freeing a page table, leaving stale CPU paging-structure-cache entries that can be speculatively accessed or cause the freed table to be reused with potentially attacker-controlled data. No public exploit code or active exploitation (CISA KEV) has been confirmed at time of analysis, and the 0.20% EPSS score reflects the complexity of reliable exploitation.
Server-side request forgery and local file read in the OpenSearch Security Analytics plugin exposes authenticated users with low privileges as a vector for internal network reconnaissance and credential theft. The flaw resides in the threat intelligence feed parser, which fails to validate URL parameters submitted to the threat intel source configuration endpoint, allowing a crafted request to redirect server-side HTTP fetches to internal resources - including cloud metadata endpoints. Patch is confirmed available per Amazon's security bulletin AWS-2026-079; no public exploit code has been identified at time of analysis.
Kernel-mode stack overflow in Intel PROSet/Wireless WiFi Software for Windows allows adjacent unauthenticated attackers to crash affected systems, resulting in a full system denial of service. The flaw resides in Ring 0 (kernel privilege level) WiFi driver code, meaning a successful exploit triggers a kernel panic or Blue Screen of Death rather than a user-space crash. No public exploit or CISA KEV listing has been identified at time of analysis, and no exact patched version is confirmed in the available reference data - the Intel advisory INTEL-SA-01468 should be consulted directly.
Kernel-mode denial of service in Intel PROSet/Wireless WiFi Software for Windows allows an adjacent unauthenticated attacker to crash the target system by triggering an improper buffer restriction in the Ring 0 (kernel-level) WiFi driver component. The vulnerability carries a CVSS 4.0 score of 8.3, requires no authentication or user interaction, and is confined to adjacent-network attackers. Intel has acknowledged the issue via security advisory INTEL-SA-01468; no public exploit code exists and no CISA KEV listing has been identified at time of analysis.
Privilege escalation in the Alias Checking Trusted Module (ACTM) firmware for certain Intel Xeon processors allows a local privileged attacker to escalate to System Management Mode (SMM) execution, achieving high confidentiality and integrity impact across both the directly compromised system and subsequent systems such as co-hosted hypervisors or tenant workloads. The attack requires high-complexity local technique combined with pre-existing privileged user access, placing it firmly in the advanced persistent threat actor category. No public exploit has been identified at time of analysis, and Intel has published advisory INTEL-SA-01439 to address this firmware flaw.
Privilege escalation in Intel PROSet/Wireless WiFi Software for Windows allows local unprivileged code operating within the Ring 2 privileged process boundary to elevate access rights due to improper privilege management (CWE-269), yielding high availability impact and limited confidentiality and integrity exposure on both the vulnerable and subsequent systems. The attack is constrained to local access and requires high complexity, but no prior authentication or user interaction is needed from the attacker. Intel has published advisory INTEL-SA-01468 to address this flaw; no public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
Improper authentication (CWE-287) in Intel's Trust Domain Extensions (TDX) module allows a Ring-0 system software adversary with high privileges to breach Trust Domain isolation boundaries, enabling information disclosure and privilege escalation. Affects select Intel platforms running TDX with a high-complexity, locally-executed attack path - no user interaction required. No public exploit identified at time of analysis, but the confidential-computing trust model is fundamentally undermined if exploited: an adversary with hypervisor-level access could read or modify memory intended to be protected from exactly that privilege tier.
Denial of service in Intel PROSet/Wireless WiFi Software for Windows stems from a null pointer dereference (CWE-476) in the Ring 2 device driver layer, allowing an adjacent unauthenticated attacker to crash the affected system with no user interaction required. The CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:N/UI:N/VA:H) confirms low-complexity exploitation from the same network segment, resulting in high availability impact to the vulnerable system and residual low availability impact to subsequent systems. No public exploit code or CISA KEV entry has been identified at time of analysis, though the absence of authentication and interaction requirements makes this trivially triggerable by any adjacent network adversary.
Denial of service in Intel PROSet/Wireless WiFi Software for Windows stems from improper buffer restrictions (CWE-119) in the Ring 2 device driver layer, exploitable by an adjacent network attacker without authentication or user interaction. An attacker within Wi-Fi range or on the same network segment can trigger a driver-level crash by sending crafted wireless input, resulting in high availability impact on the target system and low availability impact on subsequent systems, with no confidentiality or integrity consequences. No public exploit code has been identified and this CVE is not listed in the CISA KEV catalog at time of analysis.
Privilege escalation in Intel PROSet/Wireless WiFi Software for Windows exposes local systems to code execution by unprivileged attackers via a Ring 2 (device driver layer) improper access control flaw. Any local process with no privileges required and no user interaction can leverage the driver's failure to enforce access boundaries to achieve local code execution, with follow-on high confidentiality impact on the broader system - consistent with a kernel-level scope change. No public exploit identified at time of analysis, and no CISA KEV listing; however, the low complexity and zero-privilege requirement make this a credible post-compromise escalation vector for threat actors with any form of local code execution already established.
Null pointer dereference in Intel PROSet/Wireless WiFi Software for Windows at the Ring 2 device driver layer enables denial of service by an unauthenticated adjacent-network attacker. Disclosed by Intel in advisory INTEL-SA-01422, the flaw affects all currently indexed versions of the software and can be triggered at low complexity with no user interaction or special attack prerequisites. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Out-of-bounds read in the kernel-mode (Ring 0) component of Intel PROSet/Wireless WiFi Software for Windows enables a denial-of-service condition against affected Windows hosts. An unauthenticated attacker with adjacent network access and the ability to satisfy specific attack requirements can trigger a kernel-level crash, resulting in high availability impact to both the vulnerable system and any subsequent system processes. No public exploit code has been identified at time of analysis, and this CVE has not been listed in the CISA Known Exploited Vulnerabilities catalog.
Denial of service in Intel PROSet/Wireless WiFi Software affects the Ring 2 device driver layer, where an improper conditions check (CWE-754) can be triggered by an adjacent, unauthenticated attacker with no user interaction required. The vulnerability collapses wireless availability on the affected host and, per the CVSS 4.0 vector, cascades to subsequent system availability as well, meaning dependent network-connected services may also be disrupted. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Out-of-bounds read in Intel PROSet/Wireless WiFi Software at the Ring 2 device driver layer allows adjacent network attackers without authentication to escalate privileges on affected Windows systems. The flaw, tracked under CWE-125, can be triggered by a low-complexity attack from the same WiFi segment or Layer 2 broadcast domain, requiring no user interaction, and yields High availability impact alongside Low confidentiality and integrity exposure. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV, but the unauthenticated adjacent attack surface is meaningful for enterprise mobile workforces on untrusted networks.
Denial of service in Intel PROSet/Wireless WiFi Software device drivers (Ring 2) allows an unauthenticated adjacent-network attacker to crash or disable the wireless subsystem on affected systems. The flaw stems from an improper conditions check (CWE-754) within the WiFi driver stack, meaning edge-case or malformed network input is not handled safely, leading to complete availability loss of the vulnerable system. No public exploit code and no CISA KEV listing have been identified at time of analysis, though the low-complexity, zero-privilege attack vector makes this straightforward to trigger from WiFi range.
Out-of-bounds write in Intel PROSet/Wireless WiFi Software for Windows device drivers (Ring 2) allows adjacent network attackers to trigger a denial of service condition without authentication or user interaction. Unauthenticated attackers on the same network segment can exploit this CWE-787 buffer overflow flaw with low complexity, causing high availability impact to the affected Windows system and low residual availability impact on subsequent systems. No public exploit code and no CISA KEV listing exist at time of analysis.
Improper access control in Intel PROSet/Wireless WiFi Software device drivers (Ring 2) allows a local unprivileged process to cause a denial of service affecting both the wireless subsystem and, to a lesser extent, downstream system integrity. Affected systems running Intel wireless drivers are exposed to any unprivileged local code - no authentication, no elevated privileges, and no user interaction are required. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in the CISA KEV catalog.
Denial-of-service in Intel PROSet/Wireless WiFi Software for Windows (Ring 2 device driver layer) allows an unauthenticated adjacent-network attacker to crash or disable the wireless driver with no user interaction. The flaw stems from an improper conditions check (CWE-754) in the driver, yielding complete loss of wireless availability on the affected system and minor downstream availability impact on subsequently connected systems. No public exploit or CISA KEV listing exists at time of analysis, and Intel has published an advisory at INTEL-SA-01422.
Intel PROSet/Wireless WiFi Software for Windows contains a null pointer dereference in Ring 0 (kernel space) that an adjacent, unauthenticated attacker can exploit to crash the target system, resulting in a denial of service. The flaw resides in the WiFi kernel driver, meaning a successful trigger causes a kernel panic (BSOD on Windows) with high availability impact on both the vulnerable component and the broader system. No public exploit code has been identified at time of analysis, and no KEV listing exists, but the adjacent-network attack vector and zero-privilege requirement make this relevant for any environment where untrusted parties share a wireless segment with Intel WiFi-equipped Windows endpoints.
Improper access control within Ring 3 (user application space) of Intel processors permits privilege escalation from authenticated local user-level access to higher system privilege levels, with high confidentiality and integrity impact on the vulnerable system. Exploitation demands local access, low-privilege authentication, high attack complexity, and specialized internal knowledge of Intel processor microarchitecture internals - substantially narrowing the realistic attacker population. No public exploit code has been identified and no CISA KEV listing exists at time of analysis, consistent with a threat relevant primarily to sophisticated, targeted adversaries.
Denial of service via improper input validation in Intel Active Management Technology (AMT) and Intel Standard Manageability firmware allows unauthenticated network-adjacent attackers to disrupt the out-of-band management interface. The CVSS 4.0 AT:P designation confirms that specific prerequisites - namely AMT being provisioned and network-accessible - must independently exist before exploitation is possible. No public exploit has been identified at time of analysis, and Intel has disclosed the issue under advisory INTEL-SA-01427.
Protection mechanism failure in Intel Data Center Attestation Primitives (Intel DCAP) enables unauthenticated network-based attackers with specialized internal knowledge to undermine the integrity of the attestation system and expose confidential data from downstream systems relying on SGX enclave verification. The vulnerability (CWE-693) is particularly impactful in confidential computing environments where DCAP serves as the trust anchor for SGX workload isolation. No public exploit has been identified at time of analysis, and Intel has published advisory INTEL-SA-01449 addressing this issue.
Out-of-bounds kernel memory access in the Linux drm/xe Intel GPU driver allows a local low-privileged user to read sensitive kernel memory, cause a kernel panic, or potentially corrupt kernel state. The flaw exists in the BO (buffer object) prefetch path of the Intel Xe GPU subsystem, where DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC (value -1) is incorrectly used as an array index into region_to_mem_type[], accessing memory before the array's base address. Discovered via AI-assisted static analysis confirmed by Intel Product Security; no public exploit or CISA KEV listing identified at time of analysis.
Buffer overflow in the Intel i915 HDCP subsystem of the Linux kernel allows a local, low-privileged user to corrupt kernel memory with potential privilege escalation to full system compromise. The bounds check on the `data->streams[]` array write executes after the overrun has already occurred, meaning any caller who can trigger this code path can write past the array boundary before the kernel detects the violation. Discovered via AI-assisted static analysis and confirmed by Intel Product Security; no public exploit exists and EPSS probability is 0.18%, indicating no observed exploitation at time of analysis.
Out-of-bounds bitmap write in the Linux kernel's Intel ICE SR-IOV driver allows a malicious Virtual Function guest to crash the host kernel or potentially escalate privileges to the host. The vulnerable function ice_parser_profile_init unconditionally passes caller-controlled ptype values from VIRTCHNL_OP_ADD_RSS_CFG into set_bit() against a statically sized 1024-bit bitmap, permitting a value such as 0xffff to write beyond the bitmap boundary and trigger a kernel NULL pointer dereference. No public exploit code has been identified and EPSS exploitation probability is low at 0.18%, but the CVSS 8.8 score and confirmed crash reproducibility signal real urgency for SR-IOV multi-tenant environments where stable-branch patches are already available.
Unbounded retry loops in BC-FJA's JNI native entropy layer cause calling threads to hang indefinitely when Intel RDSEED or RDRAND instructions persistently fail, producing a non-interruptible thread-level denial of service in any Java FIPS application backed by bc-fips 2.1.x before 2.1.3. The affected JNI seeding routine re-issues the CPU entropy instruction without any iteration limit whenever the carry flag signals failure - a condition reproducible by hardware entropy source faults, DRBG exhaustion under heavy multi-core contention, or hypervisors that do not forward these Intel instructions to guest VMs. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the conditions are routinely present in virtualized environments where hypervisors commonly withhold RDRAND/RDSEED forwarding, making this a realistic operational risk for enterprise Java FIPS deployments in cloud or VM-based infrastructure.
Remote denial of service in Thumbor's convolution filter (versions <= 7.7.7) allows an attacker to crash the Thumbor worker process with a single crafted HTTP request by passing columns=0 to the filters:convolution() URL parameter. The Python-layer input validation accepts zero via an overly permissive regex (PositiveNumber matches '0'), which propagates to a C extension that performs integer division by zero, triggering SIGFPE and killing the process on x86_64 Linux and macOS Intel. No public exploit identified at time of analysis per KEV, but a fully functional proof-of-concept is documented in the vendor's own GHSA advisory, making exploitation trivially reproducible.
Denial of service in the Linux kernel's Intel iwlwifi 'mld' Wi-Fi driver allows a firmware crash on Intel BE201/Wi-Fi 7 adapters to spiral into sustained resource exhaustion. Because iwl_mld_tx_from_txq() failed to check the in_hw_restart flag, TX frames kept being dequeued and pushed to dead firmware, each returning -EIO and being freed in a tight loop that burns CPU and churns skb allocations, causing slab fragmentation and memory pressure. There is no public exploit identified at time of analysis, EPSS risk is low (0.16%, 6th percentile), and the issue is not on CISA KEV; it is a reliability/availability bug that manifests under real load, not an attacker-driven remote exploit.
Local privilege-impacting memory corruption in the Linux kernel's Intel ice network driver allows a double-free of a transmit buffer's skb when the TX offload paths fail. When ice_tso() or ice_tx_csum() return an error, ice_xmit_frame_ring() frees the skb but leaves the 'first' tx_buf still marked ICE_TX_BUF_SKB, so a later ice_clean_tx_ring() during interface teardown frees the same skb a second time. Carries a CVSS 3.1 base of 7.8 (AV:L/PR:L), but with a low EPSS of 0.15% (5th percentile), no KEV listing, and no public exploit identified at time of analysis.
Race condition in the Linux kernel's Intel VT-d IOMMU driver allows a local low-privileged attacker to trigger inconsistent PASID table state during domain replacement, potentially producing spurious IOMMU faults and unpredictable DMA behavior with cross-scope impact. The flaw stems from non-atomic updates to 512-bit PASID entries while the Present bit is set, and no public exploit identified at time of analysis despite a high CVSS score driven by the scope-changed local attack surface.
Kernel memory corruption in the Linux iWARP Connection Manager (RDMA/iwcm) subsystem can crash systems running RDMA workloads on iWARP-capable hardware such as Intel E830 adapters. The bug, introduced by commit e1168f0 ('RDMA/iwcm: Simplify cm_event_handler()'), causes workqueue list corruption when iwcm_work items from a free list are reused while still queued, triggering a kernel BUG and panic. No public exploit identified at time of analysis and EPSS exploitation probability is very low (0.02%, 5th percentile), despite a CVSS base score of 9.8.
Out-of-bounds array access in the Linux kernel's Intel Discrete Graphics MTD driver (mtd_intel_dg.c) lets a local actor trigger kernel memory corruption when the driver enumerates NVM regions before nregions is initialized. The flaw, caught by UBSAN as an array-index-out-of-bounds at line 750, affects systems running kernel 6.17 through the pre-patch 6.18/6.19 series with Intel discrete graphics hardware. No public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.02%, 4th percentile).
Race condition in Linux kernel Intel VT-d IOMMU driver (iommu/vt-d) allows torn reads of Scalable Mode PASID table entries during teardown, producing unpredictable behavior or spurious faults on systems with Intel VT-d enabled. The flaw stems from zeroing the entire 64-byte PASID entry while the Present bit is still set, violating the VT-d spec's invalidation guidance. No public exploit identified at time of analysis, and EPSS is very low (0.02%), but a vendor patch is available across multiple stable branches.
Denial of service in the Linux kernel's EFI unaccepted-memory handling allows a boot-time kernel panic on confidential-computing guests, affecting kernels from 6.6 through the 6.19/7.0 development line. The reserve_unaccepted() routine miscalculates the memblock reservation size when the unaccepted memory table is not page-aligned, leaving the table's tail unreserved so it can be overwritten or rendered inaccessible, triggering a panic in accept_memory(). It is observed on Intel TDX VMs with larger memory sizes (e.g. >64GB); there is no public exploit identified at time of analysis and EPSS is negligible (0.02%).
Traffic Management Microkernel (TMM) crashes in F5 BIG-IP Virtual Edition and hardware platforms when SSL profiles are configured without hardware crypto acceleration, allowing remote unauthenticated attackers to cause denial of service via undisclosed traffic patterns. CVSS 7.5 (High) with network attack vector and no prerequisites. EPSS data not provided, no CISA KEV listing identified, indicating theoretical rather than observed exploitation. Vendor patch available per F5 advisory K000158082.
Local privilege escalation in Intel QuickAssist Technology (QAT) software drivers for Windows before version 1.13 lets an authenticated low-privileged user elevate to higher privileges through improper input validation in a Ring 3 user-application code path. The flaw was reported by Intel PSIRT (INTEL-SA-01387) and carries a CVSS 4.0 base of 8.5, but there is no public exploit identified at time of analysis and EPSS is a low 0.03% (8th percentile). SSVC scores exploitation as none and not automatable, consistent with a driver bug that requires prior local, authenticated access.
Local privilege escalation in Intel QuickAssist Technology (QAT) software drivers for Windows before version 1.13 lets an authenticated, unprivileged local user escalate to higher privileges via an out-of-bounds write (CWE-787) in Ring 3 user-application code. The flaw carries a CVSS 4.0 base score of 8.5 with total technical impact but is not known to be exploited - CISA's SSVC framework rates exploitation as 'none' and EPSS is negligible at 0.01% (3rd percentile), with no public exploit identified at time of analysis.
Improper access control in all versions of Intel Vision software allows a remote, unauthenticated attacker to trigger denial of service and, under low-complexity conditions, achieve remote code execution against the Ring 3 user-application layer. The CVSS 4.0 base score of 8.8 reflects high confidentiality impact with lesser integrity and availability effects; there is no public exploit identified at time of analysis, and EPSS is low at 0.20% (42nd percentile). Intel published advisory SA-01457 and CISA's SSVC framework rates exploitation as none but technical impact as total.
Local privilege-driven data corruption in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 allows a privileged local adversary to trigger an out-of-bounds write (CWE-787) in a Ring 1 device driver, causing denial of service and integrity loss. The flaw affects the vulnerable system's integrity and availability (both High) with no confidentiality impact, and carries a CVSS 4.0 base score of 8.3. There is no public exploit identified at time of analysis, and the EPSS probability is negligible at 0.01%.
Local privilege escalation in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 lets a privileged local user trigger a Ring 1 device-driver buffer overflow to execute arbitrary code and take total control of the host. The flaw carries a CVSS 4.0 base score of 9.3 with high confidentiality, integrity and availability impact on both the vulnerable and subsequent systems. There is no public exploit identified at time of analysis, and the EPSS score is negligible at 0.01% (3rd percentile), consistent with the SSVC verdict of no known exploitation.
Local privilege-abusing denial of service and information disclosure in the Intel Data Center Graphics Driver for VMware ESXi before version 2.0.2 lets a privileged local user trigger an out-of-bounds read (CWE-125) in the Ring 1 device-driver layer, potentially crashing the host and exposing adjacent memory. The flaw carries a CVSS 4.0 base score of 8.3 driven by high confidentiality and availability impact plus a scope change into subsequent systems. There is no public exploit identified at time of analysis, EPSS is negligible (0.01%), and CISA SSVC rates exploitation as 'none' and non-automatable.
Local privilege escalation in Intel QuickAssist Adapter 8960 software before version 1.13 allows an authenticated, low-privileged user to abuse an untrusted pointer dereference in a Ring 3 user-application component to gain elevated privileges on the host. The flaw yields total impact (high confidentiality, integrity, and availability) on the affected system and carries a CVSS 4.0 base score of 8.5. There is no public exploit identified at time of analysis, and EPSS rates near-term exploitation probability at just 0.01%.
Integer overflow in Linux kernel's i915 graphics driver corrupts memory mapping for DRM/GEM shmem objects larger than 4GB, causing kernel warnings, potential crashes, and incorrect memory access when Intel graphics hardware processes large buffer objects. The vulnerability manifests when scatterlist length fields overflow during folio page allocation, leading to premature termination of backing page iteration. Patch available across multiple stable kernel branches (6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0) per upstream commits. EPSS score of 0.02% (5th percentile) indicates low observed exploitation probability, and no public exploit code or CISA KEV listing exists at time of analysis.
Stack buffer overflow in Sandboxie-Plus SbieSvc proxy service enables SYSTEM privilege escalation from sandboxed processes, including Security Hardened Sandboxes. Attackers chain an information disclosure (returning up to 32KB uninitialized stack memory with ASLR/stack cookie bypass) with an unbounded memcpy overflow in the GetRawInputDeviceInfoSlave IPC handler. Intel CET shadow stacks block ROP exploitation but not the information leak itself. Vendor-released patch available in version 1.17.3. No public exploit identified at time of analysis, but attack complexity is rated high (AC:H) with low privilege requirements (PR:L), making this viable for motivated attackers targeting sandbox environments.
Use-after-free in Linux kernel Bluetooth Intel driver enables local privilege escalation to kernel code execution. Affects Linux kernel 4.3 through 7.0-rc5, with patches available in versions 6.6.131, 6.12.80, 6.18.21, 6.19.11, and 7.0. Exploitation requires local authenticated access with low privileges (CVSS PR:L). EPSS score of 0.02% (5th percentile) indicates low probability of widespread exploitation. No public exploit code or active exploitation confirmed at time of analysis, though technical details in CVE description provide implementation roadmap.
Attested TLS relay attacks in Cocos AI confidential computing system versions 0.4.0 through 0.8.2 enable attackers to impersonate genuine TEE-protected services on AMD SEV-SNP and Intel TDX platforms by extracting ephemeral TLS private keys and redirecting authenticated sessions. The architectural flaw allows an attacker with physical access or side-channel capabilities to relay attestation evidence to a different endpoint, breaking the authentication binding between the TEE and the client. No vendor-released patch is available; the vulnerability affects a specialized confidential computing platform with low EPSS probability (formal EPSS score not provided in input) and no public exploit identified at time of analysis, though formal ProVerif verification confirms the attack feasibility.
This vulnerability in Intel EPT (Extended Page Tables) paging code within Xen allows information disclosure through a use-after-free condition in cached EPT state management. When paging structures are freed before cached EPT state is flushed, stale entries can persist in the EPT cache pointing to memory ranges outside the guest's intended ownership, enabling unauthorized memory access. Xen across multiple versions is affected, with Ubuntu tracking the issue at medium priority across 7 releases and Debian across 7 releases, making this a widespread concern for virtualization infrastructure.
A cookie management issue was addressed with improved state management. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and no vendor patch available.
Arbitrary code execution in Apple Safari, iOS/iPadOS, macOS Sequoia, and visionOS occurs when processing maliciously crafted web content, with Apple confirming active exploitation on Intel-based Mac systems. The flaw is confirmed actively exploited (CISA KEV) and carries a CVSS 8.8 score requiring only user interaction (visiting a malicious page) to achieve remote code execution. EPSS at 1.55% (81st percentile) is moderate but the KEV listing signals real-world targeted abuse against Apple's WebKit-based browsing stack.
Apache Log4j2 contains a critical JNDI injection vulnerability known as 'Log4Shell' that allows unauthenticated remote code execution through crafted log messages, affecting virtually every Java application on Earth and triggering the largest vulnerability remediation effort in history.
A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels,. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. Public exploit code available.
Local privilege escalation to SYSTEM in Intel Ethernet diagnostics driver (IQVW32.sys/IQVW64.sys versions before 1.3.1.0) allows authenticated Windows users to execute arbitrary code with kernel privileges via crafted IOCTL calls to device driver interfaces. CISA confirms active exploitation in the wild (KEV-listed). Multiple public proof-of-concept exploits demonstrate exploitability across four IOCTL handlers (0x80862013, 0x8086200B, 0x8086200F, 0x80862007). With 4.99% EPSS probability (90th percentile) and confirmed real-world abuse, this represents a critical risk for systems with Intel network adapters where the diagnostic driver remains installed and unpatched.
An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs: Intel Active Management Technology (AMT) and Intel Standard Manageability (ISM). Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable SDK for UPnP Devices (aka libupnp, formerly the Intel SDK for UPnP devices). Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and EPSS exploitation probability 88.6%.
The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and other products; Oracle Solaris 11 and earlier; illumos before r13724; Joyent. Rated high severity (CVSS 7.2), this vulnerability is low attack complexity. Public exploit code available and EPSS exploitation probability 88.0%.
Host denial-of-service in illumos bhyve allows a privileged guest user to panic the host by executing a REP-prefixed MOVS or STOS instruction targeting kernel-emulated MMIO regions such as the local APIC. The flaw has existed since 2020 and affects illumos-gate and OmniOS builds prior to commit 696ecf8d, stemming from a failure to clear the VIES_REPEAT flag that leads to a VERIFY assertion in vie_advance_pc(). Publicly available exploit code exists, but no active exploitation has been confirmed.
Denuvo Anti-Tamper (through 2026-03-04) can be bypassed by locally authenticated administrators with kernel-level privileges who load a hypervisor driver that intercepts CPUID instructions and spoofs hypervisor-absence results, defeating the anti-tamper check on AMD (SimpleSvm.sys) and Intel (hyperkd.sys, hyperhv.dll) platforms. The vulnerability has a CVSS score of 1.9 (AV:L/AC:H/PR:H) and only affects the integrity of the DRM check on the attacker's own system, with no third-party victim or escalation. No public exploit identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Clean up the bus when fetching ML caps fails snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope.
An unbalanced module reference count in the Linux kernel's Intel AVS (Audio, Voice, Speech) ASoC audio driver lets a local, authenticated user leak a module reference every time a specific error path in the driver-open routine is hit, which over repeated triggering can leave the driver module permanently pinned and degrade availability (module unload/reload fails). Only systems running a vulnerable kernel build with the Intel AVS DSP audio stack present and loaded are exposed, and our assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, a low-to-moderate priority local availability issue rather than a widespread emergency. EPSS is 0.17% (5th percentile), the issue is not in CISA KEV, and no public exploit identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53 and 7.2.7 plus mainline 7.3-rc3.
Out-of-bounds read in the Linux kernel's Intel AVS ASoC audio driver can crash the kernel when a local user with low privileges causes an oversized module config ID from a DSP topology binary to index the init_configs array. The flaw is limited to local, low-privilege access on systems with Intel AVS audio hardware and the relevant driver loaded; it is not remotely reachable and, per the assessed vector, has no confidentiality or integrity impact. EPSS is low (0.17%, 5th percentile), no public exploit code has been identified at time of analysis, and vendor fixes are available in Linux 6.18.53, 7.2.7, and 7.3-rc3 or corresponding stable backports.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Prevent drain_pebs() reentry The PEBS buffer is shared by all events on a CPU, so drain_pebs() must not be reentered. If so, one instance may observe stale buffer state and potentially access out-of-bound memory. Most invocations happen in NMI context, which naturally prevents reentry. However, drain_pebs() is also reachable from process context via intel_pmu_drain_pebs_buffer(). In those paths, the PMU is often already disabled, but not guaranteed. For example, __intel_pmu_pebs_disable() only disables the target counter, so other active counters can still raise a PMI and interrupt an in-flight drain_pebs(). Here is an example, __perf_addr_filters_adjust() perf_event_stop() __perf_event_stop() x86_pmu_stop() (event->pmu->stop) intel_pmu_disable_event() intel_pmu_pebs_disable() __intel_pmu_pebs_disable() intel_pmu_drain_large_pebs() intel_pmu_drain_pebs_buffer() Introduce __intel_pmu_quiesce() and __intel_pmu_resume() helpers and use them in intel_pmu_drain_large_pebs() to disable the full PMU around the intel_pmu_drain_pebs_buffer() call, preventing reentry. Also add a warning in intel_pmu_drain_pebs_buffer() when the full PMU is not disabled.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured.
Local information disclosure in Dell Command | Intel vPro Out of Band versions prior to 4.7.2 lets an authenticated, low-privileged user on a Windows host read data that should have been restricted, because the product ships files, directories, registry keys, or objects with overly permissive default access controls (CWE-276). Per the vendor's own advisory the impact is limited to confidentiality - no integrity or availability effect - and the vector requires local access plus a valid low-privilege account (AV:L/PR:L/UI:N), which is why it scores a moderate 5.5. No KEV listing or public exploit code was identified at time of analysis, and no public exploit has been identified; real-world risk is confined to hosts where an attacker already has a foothold, so this is routine patch-cycle work rather than an emergency.
An out-of-bounds write of up to 895 bytes into static (.bss) memory can be triggered in Zephyr RTOS's Intel SEDI IPM driver (drivers/ipm/ipm_sedi.c) when the peer processor sets a doorbell payload length larger than the 128-byte incoming_data_buf. The vulnerable path is reachable when an application has registered an IPM receive callback via ipm_register_callback(), the driver's normal mode of use, and requires a local, highly privileged attacker (CVSS PR:H) with host-side ISH driver-level or raw BAR access to the device's memory-mapped register window, plus a production image built without CONFIG_DEBUG so the HAL's DBG_CHECK length guard is compiled away. The result is kernel data-structure corruption and a crash primitive - the overflow clobbers the driver context's k_sem and k_mutex and adjacent static data - but the flaw is platform-specific and locally scoped, so it is a moderate, defense-in-depth-relevant issue rather than an urgent internet-facing emergency; no public exploit identified at time of analysis, and an upstream fix commit is available.
In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix recursive locking during device registration i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: disconnect on CSA to channel 0 The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.
In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix async notifier cleanup leak on parse error isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start() In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed.
In the Linux kernel, the following vulnerability has been resolved: Revert "PCI/MSI: Unmap MSI-X region on error" This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202. Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails. When msix_setup_interrupts() fails, the call chain is: msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap: void pci_free_msi_irqs(struct pci_dev *dev) { pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) { iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } } So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer. This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh: WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 confirms iounmap() is called with NULL. Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup.
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)
In the Linux kernel, the following vulnerability has been resolved: platform/x86/intel/tpmi: use cleanup helpers in mem_write() In mem_write(), the temporary array returned by parse_int_array_user() must be released on all exit paths. Convert the array variable to use cleanup.h scope-based cleanup so it is freed automatically on return. This also moves the array declaration next to parse_int_array_user() as required by cleanup.h usage guidelines.
Kernel information disclosure and local denial of service affect Zephyr RTOS on Intel ALH-equipped hardware through an unvalidated stream_id parameter in the Intel ALH digital-audio-interface driver. A local user-mode thread holding explicit ALH device-object access can invoke the dai_get_properties_copy() syscall with an arbitrary stream_id, triggering an out-of-bounds read from the fixed 64-entry alh_handshake_map[] array and leaking one byte of kernel memory per call, along with a computed FIFO register address that can expose kernel address-space layout. No public exploit has been identified at time of analysis; exploitation is constrained to systems built with CONFIG_USERSPACE and where device-object access has been deliberately granted to untrusted threads.
Transient execution information disclosure in Intel processors allows a Ring 0 (kernel or hypervisor level) adversary to leak sensitive data across security boundaries into a subsequent system context. The flaw stems from incorrect data forwarding during speculative execution, a class of hardware-level side-channel vulnerability similar to Spectre-class attacks, requiring local access with high privileges and high attack complexity. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; however, successful exploitation enables high-confidentiality-impact cross-boundary data exposure, threatening hypervisor isolation guarantees critical in virtualized and cloud environments.