Netdev List
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Zijing Yin <yzjaurora@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH net v2] netdevsim: fib: fix use-after-free of FIB data via debugfs
Date: Sun, 31 May 2026 14:07:26 +0300	[thread overview]
Message-ID: <20260531110726.GA179107@shredder> (raw)
In-Reply-To: <20260529135718.1804031-1-yzjaurora@gmail.com>

On Fri, May 29, 2026 at 06:57:17AM -0700, Zijing Yin wrote:
> netdevsim: fib: fix use-after-free of FIB data via debugfs
> 
> Writing to the netdevsim debugfs file
> "netdevsim/netdevsimN/fib/nexthop_bucket_activity" enters
> nsim_nexthop_bucket_activity_write(), which looks up a nexthop in
> data->nexthop_ht under rtnl_lock(). If a network namespace teardown,
> devlink reload or device deletion runs concurrently, nsim_fib_destroy()
> frees that rhashtable (and the surrounding nsim_fib_data) while the
> write is still in flight, leading to a slab-use-after-free:

[...]

> The freed 1k object is the bucket table of data->nexthop_ht. Shortly
> after, the dangling table is dereferenced again and the machine also
> takes a GPF in __rht_bucket_nested() from the same call site.
> 
> The root cause is a lifetime mismatch: the debugfs files reference
> nsim_fib_data (the writer dereferences data->nexthop_ht), but the
> interface is not bracketed around the lifetime of that data.
> nsim_fib_destroy() freed both rhashtables and only removed the debugfs
> directory afterwards, and nsim_fib_create() created the debugfs files
> before the rhashtables were initialized and, on the error path, freed
> them before removing the files. debugfs keeps the file itself alive
> across a ->write() via debugfs_file_get()/debugfs_file_put()
> (fs/debugfs/file.c), but it does not keep data->nexthop_ht alive, so the
> in-flight writer dereferenced freed memory. rtnl_lock() in the writer
> does not help, because the teardown path does not take rtnl around
> rhashtable_free_and_destroy().
> 
> Fix it by bracketing the debugfs interface around the data it exposes,
> keeping nsim_fib_create() and nsim_fib_destroy() symmetric:
> 
>  - In nsim_fib_destroy(), tear down the debugfs files before the data
>    structures they reference. debugfs_remove_recursive() drops the
>    initial active-user reference and then waits for every in-flight
>    ->write() to drop its reference before returning, and rejects new
>    opens (__debugfs_file_removed(), fs/debugfs/inode.c). Once it returns,
>    no debugfs accessor can reach the FIB data, so the rhashtables and
>    nsim_fib_data can be destroyed safely. This also covers the bool knobs
>    in the same directory, which store pointers into the same
>    nsim_fib_data, and the final kfree(data).
> 
>  - In nsim_fib_create(), create the debugfs files after the rhashtables
>    and notifiers are set up. This closes the same race on the
>    error-unwind path, where a concurrent writer could otherwise observe a
>    half-constructed instance or a table that the unwind has already
>    freed. (With only the destroy-side change, a writer racing the create
>    window instead dereferences an uninitialized data->nexthop_ht.)
> 
> This is reproducible by racing, in a loop, writes to
> /sys/kernel/debug/netdevsim/netdevsimN/fib/nexthop_bucket_activity
> against a teardown of the same netdevsim instance -- a devlink reload
> ("devlink dev reload netdevsim/netdevsimN"), destroying the network
> namespace it lives in, or "echo N > /sys/bus/netdevsim/del_device". It
> was found with syzkaller; a syzkaller reproducer is available. A
> standalone C reproducer does not trigger it reliably because the race
> needs the netns-teardown/reload path.
> 
> Fixes: c6385c0b67c5 ("netdevsim: Allow reporting activity on nexthop buckets")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zijing Yin <yzjaurora@gmail.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

      reply	other threads:[~2026-05-31 11:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29 13:57 [PATCH net v2] netdevsim: fib: fix use-after-free of FIB data via debugfs Zijing Yin
2026-05-31 11:07 ` Ido Schimmel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260531110726.GA179107@shredder \
    --to=idosch@nvidia.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=yzjaurora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox