AZL-112574: CVE-2026-99236 affecting package kernel 6.6.159.1-1
In the Linux kernel, the following vulnerability has been resolved:
tracing: Reject incomplete event filter expressions
A non-empty expression normally finishes in predicateparse()'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, "commonpid == 1 || commonpid == 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 PERFEVENTIOCSETFILTER.
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 Software
Event History
Frequently Asked Questions
What access does an attacker need to reach the vulnerable code path?
The described path is reachable through PERF_EVENT_IOC_SET_FILTER using a self-targeted perf tracepoint counting event. The data does not state what privileges or permissions are required to create or configure that event.
What filter input triggers the issue?
A non-empty trace event filter expression that ends after a logical operator, optionally followed by unary ! tokens, can leave unresolved operator state. An example is "common_pid == 1 || common_pid == 2 &&".
What could happen when the malformed filter is processed?
The second pass can read prog[-1] before the forward-jump validation rejects it. Depending on adjacent slab contents, an out-of-bounds word may be copied into a branch target that passes the forward-only check.
How is the issue addressed?
The fix rejects outer-loop fallthrough after a predicate has been parsed, ensuring non-empty expressions reach finalization only after pending operators are resolved. A regression test was added for trailing logical operators and unary negations.