From: sashiko-bot@kernel.org
To: "Haoran Wang" <haoranwangsec@gmail.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: guard trace_event_get_offsets() against an empty fields list
Date: Thu, 15 Oct 2026 09:14:55 +0000 [thread overview]
Message-ID: <sashiko-outbox-172552@kernel.org> (raw)
In-Reply-To: <6ad09433.a938ce27.3282d8.5f98@mx.google.com>
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 <haoranwangsec@gmail.com>
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/6ad09433.a938ce27.3282d8.5f98@mx.google.com?part=1
next prev parent reply other threads:[~2026-10-15 9:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 8:51 [PATCH] tracing: guard trace_event_get_offsets() against an empty fields list Haoran Wang
2026-10-15 9:14 ` sashiko-bot [this message]
2026-10-15 11:57 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-172552@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=haoranwangsec@gmail.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.