Re: [PATCH v12 03/11] HWBP: Add modify_local_hw_breakpoint_addr() API

On Thu, 20 Aug 2026 09:14:43 +0900
Masami Hiramatsu (Google) <[email protected]> wrote:

> > Pre-existing issues:
> > - [High] Lockless traversal of `kprobe_blacklist` can lead to Use-After-Free during module unload.
> 
> This seems a funny hallucination... why have you pointed unrelated kprobe things??

Ah, no.

> > [Severity: High]
> > This is a pre-existing issue, but can the lockless traversal in the
> > blacklist check lead to a use-after-free during module unload?
> > 
> > When parsing the breakpoint, the call chain goes through:
> > arch_modify_local_hw_breakpoint_addr() -> hw_breakpoint_arch_parse() ->
> > arch_build_bp_info() -> within_kprobe_blacklist()

Hmm, why it checks kprobe_blacklist... that is for kprobe handlers (mainly
because avoiding obviously nested kprobes). Anyway, we can make the list
rcu-safe.

> > 
> > kernel/kprobes.c:__within_kprobe_blacklist() {
> >     ...
> >     list_for_each_entry(ent, &kprobe_blacklist, list) {
> >         if (addr >= ent->start_addr && addr < ent->end_addr)
> >             return true;
> >     }
> >     ...
> > }
> > 
> > If a module is unloaded concurrently, kprobe_remove_area_blacklist() deletes
> > entries and immediately frees them with kfree(). Would a concurrent hardware
> > breakpoint modification dereference freed memory here since kprobe_mutex
> > is not held and RCU protection is not used?

Yes, it will be possible.

Thanks,

> > 
> > > +	if (ret) {
> > > +		counter_arch_bp(bp)->address = old_addr;
> > > +		bp->attr.bp_addr = old_addr;
> > > +		return ret;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > 
> > -- 
> > Sashiko AI review · https://sashiko.dev/#/patchset/178611679753.237811.10190793347982785419.stgit@devnote2?part=3
> 
> 
> -- 
> Masami Hiramatsu (Google) <[email protected]>


-- 
Masami Hiramatsu (Google) <[email protected]>