Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] tracing: 0 bound rejects valid 32-bit BPF access to common_pid --
commit 5b3e91afc57d96231d6f6b70552ed4d6b24e6d5c Author: Haoran Wang <[email protected]> Subject: tracing: guard trace_event_get_offsets() against an empty fields list This commit adds a list_empty() check to trace_event_get_offsets() to prevent a wild pointer dereference when a tracepoint has no event-specific fields. It returns 0 when the list is empty to prevent out-of-bounds reads. > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > index 30c0ddf90887f..bf5377fbc7b71 100644 > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -241,6 +241,8 @@ int trace_event_get_offsets(struct trace_event_call *call) > struct list_head *head; > > head = trace_get_fields(call); > + if (list_empty(head)) > + return 0; [Severity: Medium] Will returning 0 here artificially shrink the context bound below the inherent 8 bytes of struct trace_entry, potentially breaking 32-bit BPF accesses to common_pid? On 32-bit architectures where sizeof(void *) is 4, the verifier in tp_prog_is_valid_access() allows reads to offsets >= 4, making the pid field (offset 4, size 4) structurally valid to read: kernel/trace/bpf_trace.c:tp_prog_is_valid_access() { if (off < sizeof(void *) || off >= PERF_MAX_TRACE_SIZE) return false; ... } If such a program is attached to a zero-field tracepoint, trace_event_get_offsets() will return 0. Then in __perf_event_set_bpf_prog(): kernel/events/core.c:__perf_event_set_bpf_prog() { ... int off = trace_event_get_offsets(event->tp_event); if (prog->aux->max_ctx_offset > off) return -EACCES; ... } Since max_ctx_offset for this read is 8, the condition evaluates to 8 > 0, falsely rejecting valid BPF tracepoint programs with -EACCES. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
