From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: Daniel Paziyski <danielpaziyski@gmail.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Fix null pointer dereference in trace_kvm_inj_exception
Date: Fri, 10 Jul 2026 11:35:21 -0700 [thread overview]
Message-ID: <alE7aTGmUIWKJf9a@google.com> (raw)
In-Reply-To: <20260710135312.AD74F1F000E9@smtp.kernel.org>
On Fri, Jul 10, 2026, sashiko-bot@kernel.org wrote:
> > An empty struct is being passed, which makes the
> > kernel derefence a NULL pointer when the error code is 0. Remove this
> > stray struct in the invocation of __print_symbolic.
>
> [Severity: Medium]
> Is this description of a null pointer dereference accurate?
Yes, it is. Sashiko apparently applied to an old base (pre-7.1). As of commit
754e38d2d1ae ("tracing: Use explicit array size instead of sentinel elements in
symbol printing") (spoiler alert), trace_print_symbols_seq() is:
for (i = 0; i < symbol_array_size; i++) {
if (val != symbol_array[i].mask)
continue;
trace_seq_puts(p, symbol_array[i].name);
break;
}
> Looking at how __print_symbolic expands, the empty struct { } safely
> initializes the first element's name pointer to NULL. When
> trace_print_symbols_seq() is called, it handles this gracefully:
>
> kernel/trace/trace_output.c:trace_print_symbols_seq() {
> ...
> for (i = 0; symbol_array[i].name; i++) {
> ...
> }
>
> Since the name field is NULL for the first element, the loop is bypassed
> entirely and the function safely falls back to printing the error code as a
> hex string without dereferencing a NULL pointer.
>
> > diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
> > --- a/arch/x86/kvm/trace.h
> > +++ b/arch/x86/kvm/trace.h
> > @@ -490,7 +490,7 @@ TRACE_EVENT(kvm_inj_exception,
> > TP_printk("%s%s%s%s%s",
> > __print_symbolic(__entry->exception, kvm_trace_sym_exc),
> > !__entry->has_error ? "" : " (",
> > - !__entry->has_error ? "" : __print_symbolic(__entry->error_code, { }),
> > + !__entry->has_error ? "" : __print_symbolic(__entry->error_code),
>
> [Severity: Low]
> Will this change break the kernel build?
No, beacuse again, Sashiko applied to an old base for some reason.
next prev parent reply other threads:[~2026-07-10 18:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 13:40 [PATCH] KVM: x86: Fix null pointer dereference in trace_kvm_inj_exception Daniel Paziyski
2026-07-10 13:53 ` sashiko-bot
2026-07-10 18:35 ` Sean Christopherson [this message]
2026-07-10 18:42 ` Sean Christopherson
2026-07-10 19:34 ` Daniel Paziyski
2026-07-13 11:02 ` Thomas Weißschuh
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=alE7aTGmUIWKJf9a@google.com \
--to=seanjc@google.com \
--cc=danielpaziyski@gmail.com \
--cc=kvm@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.