On 7/20/2026 11:26 AM, Marco Elver wrote: > On Fri, 17 Jul 2026 at 14:50, Jinchao Wang <[email protected]> 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/[email protected]/). > > 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
