CVE-2026-68175
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux diagnostic tracing can waste memory each time certain log files are opened and closed, and doing this many times may eventually slow down or crash the system.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability causes a resource leak where closing the trace_pipe file with the mmiotrace tracer active fails to free an allocated header_iter structure and release a pci_dev reference because mmio_close is only attached to the .close callback rather than .pipe_close.
Why it matters to the business
Repeated triggering can lead to gradual memory exhaustion and resource depletion in systems using mmiotrace tracing, potentially causing instability or denial of service over time.
How an attack unfolds
An attacker with access to the tracing interface activates mmiotrace and repeatedly opens trace_pipe then performs partial reads such as head -n 1 without allowing full completion, causing the kernel to leak header_iter allocations and pci_dev references on each close.
How to fix it
Apply the upstream kernel patch that sets the .pipe_close callback to mmio_close in the mmiotrace tracer so that tracing_release_pipe properly invokes resource cleanup.
How to confirm the fix worked
Inspect the tracer registration code to confirm .pipe_close points to mmio_close, or execute repeated partial reads of trace_pipe under mmiotrace and verify that header_iter and pci_dev references are released.
Typical attack path
- Obtain local access sufficient to interact with /sys/kernel/tracing
- Enable the mmiotrace tracer
- Repeatedly execute partial reads against trace_pipe
- Observe progressive increase in unreleased memory and device references
How to detect it
Review system logs and tracing subsystem activity for repeated opens and partial reads of trace_pipe while mmiotrace is enabled; correlate with rising slab or pci device reference counts that do not decrease after file closure.
What your security team should do
- Update to a Linux kernel containing the mmiotrace pipe_close fix
- Restrict unprivileged access to the tracing filesystem when mmiotrace is not required
- Monitor kernel memory statistics for unexpected growth correlated with tracing activity
The record
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|