Re: [BUG] sunrpc: cache_seq_start_rcu() slab-out-of-bounds (unpriv-userns reachable)
From: Chuck Lever
Date: Thu May 28 2026 - 13:47:44 EST
On Thu, May 28, 2026, at 12:53 PM, Farhad Alemi wrote:
> Hello Chuck and the linux-nfs team,
>
> I am reporting a sunrpc cache slab-out-of-bounds read found by syzkaller.
> Flagging up front because the read site is reachable from an unprivileged
> user via unshare(CLONE_NEWUSER|CLONE_NEWNET) on distros that enable
> unprivileged user-namespace creation by default.
>
> Summary:
> A read(2) on any sunrpc-cache seq_file (e.g. the nfsd virtual
> filesystem's /exports, or /proc/net/rpc/<cache>/content) drives
> cache_seq_start_rcu() -> __cache_seq_start() at net/sunrpc/cache.c:1351.
> After the iterator walks all hash buckets, __cache_seq_start writes back
> *pos = ((long long)cd->hash_size << 32) + 1 (the literal final-line
> assignment in the function). The next read re-enters __cache_seq_start
> with that *pos, decodes hash = cd->hash_size, and the very first
> hlist_for_each_entry_rcu() walks &cd->hash_table[hash] one element past
> the array end. The existing "while (!ch && ++hash < cd->hash_size)"
> check only guards later iterations within the function, not the entry
> hlist_for_each_entry_rcu().
>
> The KASAN-reported 2K allocation is cd->hash_table allocated by
> kzalloc_objs(struct hlist_head, cd->hash_size) in cache_create_net() at
> net/sunrpc/cache.c:1733; struct cache_detail itself is a separate,
> smaller kmemdup at line 1729. The 8-byte OOB read at the right edge of
> the 2048-byte region reads hash_table[cd->hash_size] -- one struct
> hlist_head past the end of the table.
>
> Observed on:
> - Linux v7.1-rc3-200-g70eda68668d1-dirty, x86_64, QEMU Q35
> - KASAN enabled; panic_on_warn set
> - The only local dirty file in my tree is drivers/tty/serial/serial_core.c,
> containing a local ttyS0 console guard for the fuzzing harness. It is
> unrelated to net/sunrpc/.
> - __cache_seq_start() at net/sunrpc/cache.c:1351 still walks
> &cd->hash_table[hash] without bounding the decoded hash against
> cd->hash_size before the first iteration; bug remains reachable on
> current mainline.
Hi Farhad -
Your report appears to be an independent rediscovery of a bug syzbot
already reported and which we've already fixed. The fix was pushed
this week to Linus for merge into v7.1-rc5.
Your novelty check noted that you searched the syzbot dashboard but
did not find a match. See syzbot instance ID 60cfa08822470bbebe44.
--
Chuck Lever