From: sashiko-bot@kernel.org
To: "Kyle Zeng" <kylebot@openai.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf/hw_breakpoint: Avoid leaking private x86 breakpoint ranges
Date: Tue, 06 Oct 2026 22:44:55 +0000 [thread overview]
Message-ID: <sashiko-outbox-162494@kernel.org> (raw)
In-Reply-To: <20261006222519.43193-1-kylebot@openai.com>
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
next prev parent reply other threads:[~2026-10-06 22:45 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 [this message]
2026-10-07 5:44 ` Kyle Zeng
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-162494@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=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.