CVE-2026-64299: tracing: Prevent out-of-bounds read in glob matching
In the Linux kernel, the following vulnerability has been resolved:
tracing: Prevent out-of-bounds read in glob matching
String event fields are not necessarily NUL-terminated, so the filter predicate functions (filterpredstring(), filterpredstrloc() and filterpredstrrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.
regexmatchglob() was the exception: it ignored the length and called globmatch(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in globmatch(), reached via regexmatchglob() and filtermatchpreds() from the xfslookup tracepoint.
Add a length-bounded globmatchlen() and use it from regexmatchglob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so globmatch() keeps its behaviour.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the tracing/glob matching implementation so regex_match_glob() and the shared glob matcher honor the provided event field length (via a new length-bounded helper glob_match_len()), ensuring matching stops at the field boundary rather than scanning until a NUL byte.
Linux kernel tracing glob matching (regex_match_glob/glob_match_len) Length-aware glob matching = Use length-bounded glob_match_len() in regex_match_glob() (via filter_match_preds()/filter_pred_* callers) instead of ignoring the field length - Operational
Rebuild and deploy the updated Linux kernel with the tracing/glob matching fix applied so KASAN-confirmed out-of-bounds reads in tracing are eliminated.
Event History
Frequently Asked Questions
Who can trigger this issue?
The CVSS vector indicates local access with low privileges is required and no user interaction is needed. Exploitation also depends on reaching tracing filter glob matching against a string event field that is not NUL-terminated.
Which trace data is known to be affected?
The dynamic character array used by xfs_* namespace tracepoints is identified as an example because it is copied without a trailing NUL byte. The reported out-of-bounds read was reached from the xfs_lookup tracepoint.
How would this appear on an affected system?
The issue can produce a KASAN slab-out-of-bounds read in glob_match(), called through regex_match_glob() and filter_match_preds(). It occurs when glob matching scans beyond the boundary of a non-NUL-terminated event field.