All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyle Zeng <kylebot@openai.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf/hw_breakpoint: Avoid leaking private x86 breakpoint ranges
Date: Tue, 6 Oct 2026 22:44:12 -0700	[thread overview]
Message-ID: <asXcLNxqlPMILbxn@com-75606> (raw)
In-Reply-To: <sashiko-outbox-162494@kernel.org>

On Tue, Oct 06, 2026 at 10:44:55PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] perf/hw_breakpoint: memcmp validates uninitialized flag-gated fields
> --
> 
> commit 0cb8c384abc8b74fee8923d87b586e123993d285
> Author: Kyle Zeng <kylebot@openai.com>
> 
> perf/hw_breakpoint: Avoid leaking private x86 breakpoint ranges
> 
> This commit addresses a security issue where private x86 breakpoint ranges
> can be leaked to unprivileged callers by validating immutable attributes
> before parsing a modify request. It also checks x86 kernel-breakpoint
> access before consulting private blacklists and validates instruction
> lengths early.
> 
> > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
> > index 789add0c185a0..1f0e7f63ba82c 100644
> > --- a/kernel/events/hw_breakpoint.c
> > +++ b/kernel/events/hw_breakpoint.c
> [ ... ]
> > @@ -765,10 +765,6 @@ modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr *a
> >  	struct arch_hw_breakpoint hw = { };
> >  	int err;
> >  
> > -	err = hw_breakpoint_parse(bp, attr, &hw);
> > -	if (err)
> > -		return err;
> > -
> >  	if (check) {
> >  		struct perf_event_attr old_attr;
> >  
> > @@ -778,6 +774,10 @@ modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr *a
> >  			return -EINVAL;
> 
> [Severity: Medium]
> Does this memcmp() inappropriately enforce equality on uninitialized, unused,
> and flag-gated fields?
> 
> Userspace is not required to zero unused fields in the perf_event_attr struct.
> If a user opens a hw_breakpoint event with uninitialized stack garbage in
> unused fields (e.g., sample_regs_user, config2), and later calls
> PERF_EVENT_IOC_MODIFY_ATTRIBUTES with a new perf_event_attr to modify bp_addr,
> the new struct may contain different stack garbage.
> 
> Since perf_copy_attr() copies the struct verbatim from userspace, this
> memcmp() fails when comparing the original and new structs due to the
> differing uninitialized bytes. This will spuriously reject valid modification
> requests with -EINVAL.
> 
> >  	}
> >  
> > +	err = hw_breakpoint_parse(bp, attr, &hw);
> > +	if (err)
> > +		return err;
> > +
> >  	if (bp->attr.bp_type != attr->bp_type) {
> >  		err = modify_bp_slot(bp, bp->attr.bp_type, attr->bp_type);
> >  		if (err)
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261006222519.43193-1-kylebot@openai.com?part=1

old_attr is initialized in hw_breakpoint_copy_attr. I don't see use of
uninitialized data in the path.

Best,
Kyle

      reply	other threads:[~2026-10-07  5:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 22:25 [PATCH] perf/hw_breakpoint: Avoid leaking private x86 breakpoint ranges Kyle Zeng
2026-10-06 22:44 ` sashiko-bot
2026-10-07  5:44   ` Kyle Zeng [this message]

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=asXcLNxqlPMILbxn@com-75606 \
    --to=kylebot@openai.com \
    --cc=linux-perf-users@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.