On Wed, Mar 25, 2026 at 09:34:40AM +0100, Vlastimil Babka (SUSE) wrote:
> On 3/25/26 09:21, Harry Yoo (Oracle) wrote:
> > On Wed, Mar 25, 2026 at 08:50:07AM +0100, Vlastimil Babka (SUSE) wrote:
> >> On 3/24/26 22:35, Jann Horn wrote:
> >> > Disable CONFIG_KVFREE_RCU_BATCHED in CONFIG_RCU_STRICT_GRACE_PERIOD
> >> > builds
> >> > so that kernel fuzzers have an easier time finding use-after-free
> >> > involving
> >> > kfree_rcu().
> >> >
> >> > The intent behind CONFIG_RCU_STRICT_GRACE_PERIOD is that RCU should
> >> > invoke
> >> > callbacks and free objects as soon as possible (at a large performance
> >> > cost) so that kernel fuzzers and such have an easier time detecting
> >> > use-after-free bugs in objects with RCU lifetime.
> >> >
> >> > CONFIG_KVFREE_RCU_BATCHED is a performance optimization that queues
> >> > RCU-freed objects in ways that CONFIG_RCU_STRICT_GRACE_PERIOD can't
> >> > expedite; for example, the following testcase doesn't trigger a KASAN
> >> > splat
> >> > when CONFIG_KVFREE_RCU_BATCHED is enabled:
> >> > ```
> >> > struct foo_struct {
> >> > struct rcu_head rcu;
> >> > int a;
> >> > };
> >> > struct foo_struct *foo = kmalloc(sizeof(*foo),
> >> > GFP_KERNEL | __GFP_NOFAIL | __GFP_ZERO);
> >> >
> >> > pr_info("%s: calling kfree_rcu()\n", __func__);
> >> > kfree_rcu(foo, rcu);
> >> > msleep(10);
> >> > pr_info("%s: start UAF access\n", __func__);
> >> > READ_ONCE(foo->a);
> >> > pr_info("%s: end UAF access\n", __func__);
> >> > ```
> >> >
> >> > Signed-off-by: Jann Horn <[email protected]>
> >>
> >> Hm but with 7.0 we have sheaves everywhere including kmalloc caches, and
> >> there's a percpu rcu_free sheaf collecting kfree_rcu'd objects.
> >
> > Right, but only when CONFIG_KVFREE_RCU_BATCHED=y
> >
> >> Only when
> >> it's full it's submitted to call_rcu() where the callback rcu_free_sheaf()
> >> runs slab_free_hook() including kasan hooks etc. If there's nothing filling
> >> the rcu_free sheaf, the objects can sit there possibly indefinitely.
> >
> > Right.
> >
> >> That means CONFIG_KVFREE_RCU_BATCHED now handles only the rare cases where
> >> kfree_rcu() to the rcu_free sheaf fails (and I still owe it to Ulad to do
> >> something about this).
> >
> > Right.
> >
> >> So to complete the intent of this patch, we should perhaps also skip the
> >> rcu_free sheaf with RCU_STRICT_GRACE_PERIOD? (or with !KVFREE_RCU_BATCHED
> >> perhaps as it's also a form of batching).
> >
> > Maybe I'm missing something, but...
> >
> > by making KVFREE_RCU_BATCHED depend on !RCU_STRICT_GRACE_PERIOD,
> > selecting RCU_STRICT_GRACE_PERIOD disables all uses of rcu_free sheaves?
> >
> > kvfree_call_rcu() implementation on !KVFREE_RCU_BATCHED does not call
> > kfree_rcu_sheaf().
>
> Ah yeah, I missed that there are two kvfree_call_rcu() implementations and
> kfree_rcu_sheaf() is only used in the batched one. Sorry for the noise.
It's confusing indeed. I was trapped by this yesterday, thinking...
"Oh, why doesn't kvfree_rcu_barrier() on !KVFREE_RCU_BATCHED flush
rcu sheaves? It's broken!"
and then realized that I was confused :)
> Will queue the patch
Thanks!
--
Cheers,
Harry / Hyeonggon
