Re: [PATCH] refcount: Use CONFIG_BUG_ON_DATA_CORRUPTION for UAF-related errors

[Jann Horn]

On Tue, Sep 29, 2026 at 3:14 PM Will Deacon <will@xxxxxxxxxx> wrote:
> On Wed, Aug 12, 2026 at 08:56:38PM +0200, Jann Horn wrote:
> > Some refcount issues are not necessarily associated with memory corruption,
> > but REFCOUNT_ADD_UAF suggests that a UAF either just happened or is about
> > to happen.
> >
> > REFCOUNT_SUB_UAF is also an indicator that reference counting is wrong, and
> > suggests (less strongly) that a UAF access might have happened recently.
> >
> > In these cases, BUG() is appropriate if CONFIG_BUG_ON_DATA_CORRUPTION is
> > set.
> >
> > Signed-off-by: Jann Horn <jannh@xxxxxxxxxx>
> > ---
> > MAINTAINERS specifies no specific maintainer for lib/refcount.c, but it
> > does have an entry for include/linux/refcount.h, so I guess I should
> > route this patch based on that.
> >
> > I decided to send this patch after wondering how exploitable it would be
> > to have a refcount_inc() call on an object which has reached refcount 0,
> > but is not yet freed because of something like an RCU grace period.
> > ---
> >  lib/refcount.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/refcount.c b/lib/refcount.c
> > index a207a8f22b3c..c0f0dc5296eb 100644
> > --- a/lib/refcount.c
> > +++ b/lib/refcount.c
> > @@ -10,6 +10,15 @@
> >
> >  #define REFCOUNT_WARN(str)   WARN_ONCE(1, "refcount_t: " str ".\n")
> >
> > +#ifdef CONFIG_BUG_ON_DATA_CORRUPTION
> > +#define REFCOUNT_CORRUPTION(str) ({          \
> > +     pr_err("refcount_t: " str ".\n");       \
> > +     BUG();                                  \
> > +})
> > +#else
> > +#define REFCOUNT_CORRUPTION(str) REFCOUNT_WARN(str)
> > +#endif
>
> Can you use CHECK_DATA_CORRUPTION() here instead of open-coding the BUG()?

I was considering that, but decided not to for two reasons:

1. CHECK_DATA_CORRUPTION() uses WARN(), while the refcounting code
uses WARN_ONCE() so that a saturated refcount doesn't WARN() every
time it is touched.
2. CHECK_DATA_CORRUPTION() is currently marked with __must_check
(which can't reliably be suppressed on all compilers by casting the
result to void), see
https://lore.kernel.org/all/20260812-data-corruption-mustcheck-v1-1-5f59bd3bc2b8@xxxxxxxxxx/
.

> Either way:
>
> Acked-by: Will Deacon <will@xxxxxxxxxx>

Thanks!