CVE-2026-99236
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Nov 2, 2026
CISA due date
—
Cloudanix analysis
A flaw in the Linux kernel's tracing feature lets a local user send a malformed command that can give them complete control over the computer.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Out-of-bounds memory read and potential write in predicate_parse() when an incomplete event filter expression ends after a logical operator or unary negation, leaving unresolved operator state that causes prog[-1] access and possible branch target corruption.
Why it matters to the business
Local attackers can achieve kernel-level code execution or information disclosure on affected Linux systems, leading to full host compromise; the flaw was published only one day ago and carries high severity, requiring immediate attention.
How an attack unfolds
A local user creates a perf tracepoint counting event and issues PERF_EVENT_IOC_SET_FILTER with a trailing-operator expression such as "common_pid == 1 || common_pid == 2 &&", causing the parser to fall through the outer loop with unresolved state and perform an out-of-bounds access that can be leveraged for arbitrary memory operations.
How to fix it
Upgrade the Linux kernel to a version containing the fix that rejects outer-loop fallthrough when a predicate has already been parsed and includes the added regression test for trailing operators; restrict unprivileged perf_event_paranoid settings until patched.
How to confirm the fix worked
Verify the presence of the rejection logic for unresolved operator state in predicate_parse() and execute the regression test that supplies trailing logical operators and unary negations to confirm the input is rejected before finalization.
Typical attack path
- Obtain local unprivileged access on a Linux host
- Create a perf event via perf_event_open
- Submit an incomplete filter expression via PERF_EVENT_IOC_SET_FILTER
- Trigger predicate_parse() to perform out-of-bounds read/write
- Escalate to kernel code execution or leak sensitive data
How to detect it
Review audit logs and perf-related kernel messages for ioctl calls on tracepoint events containing filter strings that end with logical operators; correlate with any subsequent kernel oops or slab corruption reports.
What your security team should do
- Apply the upstream kernel patch or distribution update within the next 48 hours given the recent publication date
- Set kernel.perf_event_paranoid to 2 or higher to limit unprivileged perf access
- Audit systems for use of perf tracepoint filters and disable tracing subsystems where not required
The record
In the Linux kernel, the following vulnerability has been resolved: tracing: Reject incomplete event filter expressions A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|