In the Linux kernel, the following vulnerability has been resolved: tracing: Reject incomplete…

Why it is Yellow

• CVSS 7.8 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/1008e9e0b8280d47f1ab5e9c113f666a023a9697
• https://git.kernel.org/stable/c/15ff3cc7f2beecc3f95d66358f20ad7b057466aa
• https://git.kernel.org/stable/c/2a98f5d4913ec081e08e1075512cb7ec313d9f72
• https://git.kernel.org/stable/c/4a1a6d35359991c5d47f4bf101cfbe1475c94093
• https://git.kernel.org/stable/c/5a999b5a16530898f0dbe5f8c50fd45ea72e110b
• https://git.kernel.org/stable/c/5bcdf3c18c3471122ee9652b0e2f5cdb718d9a46
• https://git.kernel.org/stable/c/64993d970dde2a2da353e9e99595a4fa88ec27d9
• https://git.kernel.org/stable/c/b205ff58e02922ac324f931cf9eb238a3acdb048

Original description

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.