Linux Trace Kernel
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: sashiko-bot@kernel.org
Cc: sashiko-reviews@lists.linux.dev,
	"Linux trace kernel" <linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/probes: Zero out faulted dereferenced fields
Date: Thu, 12 Nov 2026 10:17:56 -0500	[thread overview]
Message-ID: <20261112101756.0ff021f9@fedora> (raw)
In-Reply-To: <sashiko-outbox-208768@kernel.org>

On Wed, 11 Nov 2026 10:17:13 +0000
sashiko-bot@kernel.org wrote:

> 
> [Severity: Medium]
> Does this still leave the trace event field uninitialized in the ring
> buffer when an intermediate dereference faults in stage 2 of
> process_fetch_insn_bottom()?
> 
> In the commit message's "(task_struct)prev->mm->pgd" example, prev is
> valid and prev->mm is NULL, so stage 2 (FETCH_OP_DEREF) succeeds and loads
> val = 0, and the fault happens on the final dereference in stage 3
> (FETCH_OP_ST_MEM), where dest points to the ring buffer field.
> 
> However, if a chain has another dereference after the NULL pointer (such as
> "(task_struct)prev->mm->exe_file->f_inode" when prev->mm is NULL), the
> fault happens in stage 2:
> 
> kernel/trace/trace_probe_tmpl.h:process_fetch_insn_bottom() {
>     ...
> stage2:
> 	/* 2nd stage: dereference memory if needed */
> 	do {
> 		lval = val;
> 		switch (code->op) {
> 		case FETCH_OP_DEREF:
> 			ret = probe_mem_read(&val, (void *)val + code->offset,
> 					     sizeof(val));
> 			break;
> 		case FETCH_OP_UDEREF:
> 			ret = probe_mem_read_user(&val,
> 				 (void *)val + code->offset, sizeof(val));
> 			break;
>     ...
> 		}
> 		if (ret)
> 			return ret;
>     ...
> }
> 
> Here probe_mem_read() only zeroes the stack variable val, and
> process_fetch_insn_bottom() returns early before reaching stage 3.
> Because store_trace_args() ignores a negative return value from
> process_fetch_insn(), the destination field in the ring buffer is never
> written to and retains stale ring buffer data (or, for a dynamic string
> argument, keeps the pre-initialized *dl = make_data_loc(maxlen, ...)
> header without calling set_data_loc()).
> 

Right.

This is the same issue but in a separate spot. I think this fix should
be folded into this patch. That fix would actually be to ignore the
return value from probe_mem_read*(), as a fault would simply make val
zero, and if we are dereferencing it, we should allow it to continue
with a NULL pointer but detect that too.

-- Steve

  reply	other threads:[~2026-11-12 15:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 10:03 [PATCH] tracing/probes: Zero out faulted dereferenced fields Steven Rostedt
2026-11-11 10:17 ` sashiko-bot
2026-11-12 15:17   ` Steven Rostedt [this message]
2026-11-11 10:21 ` 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=20261112101756.0ff021f9@fedora \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-bot@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox