Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption

[Jinchao Wang <wangjinchao600@gmail.com>]

On 7/20/2026 11:26 AM, Marco Elver wrote:
> On Fri, 17 Jul 2026 at 14:50, Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>
>> Motivation
>> ==========
>>
>> The hardest memory corruption bugs are the silent ones: a rogue writer
>> scribbles over a live object through a stale pointer or a race, and
> 
Thanks, Marco. These are good points. My cover letter did not clearly
separate two different classes of bugs.

> The stale/dangling pointer (use-after-free) case is the main one you're after?

Not exclusively. KASAN already does a good job as a general
use-after-free detector. However, a stale-pointer write after the
storage has been recycled, which may no longer be reported by Generic
KASAN, is one of the cases that the scoped watchpoint can help
localize.

The broader target is silent corruption of a known live victim object,
including non-UAF cases such as an in-bounds racing write to an object
whose allocation is still live.

>> the victim crashes in a code path far away from the culprit. Any
>> single developer hits such a bug rarely, but across the kernel's code
>> base and install base they keep arriving, and each one is
>> disproportionately expensive to localize. The question to answer is
>> "who wrote to this object, and from where?", and it is hard to get at
>> with the existing tools:
>>
>>  - The kernel's own reports - an oops on a clobbered pointer, a
>>    BUG_ON, a list-corruption warning - fire at the victim's access,
>>    not at the corrupting write.
>>  - KASAN/KFENCE catch memory-safety violations: out-of-bounds
>>    accesses and use-after-free. But they have a blind spot: a
>>    corrupting write can be fully memory-safe - a *valid* pointer, in
> 
> Language-semantically speaking, a use-after-free write to recycled
> memory (be it in heap or stack) is NOT memory-safe. The detectors may
> not always catch these (KASAN relies on quarantine for that to
> increase the chances, but yeah, not guaranteed..).
> 

You are right that a stale-pointer write to recycled storage remains a
use-after-free, so "memory-safe" was the wrong term. What I meant was
that such a corrupting write may not be detected by Generic KASAN at
the point where it occurs. KWatch was intended to use a hardware
watchpoint to catch the write and report the actual writer and its call
stack.

>>    bounds, to a live object, written just at the wrong time or to the
>>    wrong place - and then they stay silent by design. And even for
>>    the bugs they can catch, KASAN's rebuild, overhead and redzones
>>    change timing and layout enough that racy corruption often no
>>    longer reproduces.
> 
> There's also tag-based KASAN (KASAN_SW_TAGS or KASAN_HW_TAGS), of
> which KASAN_SW_TAGS has an x86 version based on LAM (not yet merged
> though? see https://lwn.net/ml/all/cover.1773164688.git.m.wieczorretman@pm.me/).
> 
> One property of tag-based schemes (and any other lock+key detection
> scheme) is that upon recycling some memory, the tag (or key) to that
> location changes, and any previous pointer that still has the old tag
> will fault. The caveat with current pointer-tagging schemes is that
> entropy is relatively low (4 bit tags).
Thanks for pointing this out. I agree that tag-based KASAN can detect a
recycled-storage UAF when the new allocation receives a different tag,
so it covers part of the intended use case.

There are still cases it cannot detect, such as an in-bounds corrupting
write to the same still-live allocation, or a recycled allocation which
reuses the same tag. Software tag-based KASAN also still instruments
memory accesses and can perturb a timing-sensitive bug enough that it
no longer reproduces; hardware tag checking reduces this overhead but
is not available everywhere.

The original goal of KWatch, which I now plan to pursue through wprobe,
was to provide a simple and targeted interface to hardware watchpoints.
It does not instrument every memory access system-wide, so it can have
lower overall overhead and less timing perturbation while identifying
the actual writer. I see this as complementary to KASAN rather than a
replacement for it.

Thanks,
Jinchao