From: Greg KH <greg@kroah.com>
To: 徐晗翔 <xuhx@hust.edu.cn>
Cc: dakr@kernel.org, rafael@kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: driver core: uevent: netns teardown frees uevent_sock while a tagged uevent is still being broadcast (UAF)
Date: Tue, 10 Nov 2026 13:48:48 -0500 [thread overview]
Message-ID: <2026111041-plasma-dreadlock-df34@gregkh> (raw)
In-Reply-To: <21f226b6.22aca.1a1c58bb374.Coremail.xuhx@hust.edu.cn>
On Tue, Nov 10, 2026 at 09:00:29PM +0800, 徐晗翔 wrote:
> net->uevent_sock is published as a bare pointer by uevent_net_init()
> and freed by uevent_net_exit(), but the tagged broadcast path
> dereferences net->uevent_sock->sk without holding uevent_sock_mutex or
> taking a socket reference. uevent_net_exit() drops the mutex before
> releasing the socket and never clears net->uevent_sock, so a kobject
> whose namespace callback returns an unpinned net pointer can emit a
> tagged uevent after the per-net exit has freed the socket; KASAN
> reports a slab-use-after-free read in kobject_uevent_net_broadcast()
> (inlined into kobject_uevent_env in the report below).
>
> An IB compat device supplies a concrete path. Its rdma_net is a raw
> possible_net_t, and its asynchronous unregister can still be inside
> device_del() after the net namespace has run uevent_net_exit(). This
> was reported by syzbot (KASAN: slab-use-after-free Read in
> disable_device, extid 4393dfdddf166f2de2b0,
> https://syzkaller.appspot.com/bug?extid=4393dfdddf166f2de2b0) and I
> reproduced it locally on 7.3 with a KASAN kernel; the same reproducer
> is clean with a no-rxe control and with the v4 locking change described
> below.
>
> The detailed description:
>
> * Test environment / affected version
>
> Linux 7.3.0 (vanilla mainline tarball), x86_64, QEMU/KVM guest,
> 8 vCPU / 4 GB RAM, KASAN generic. The tested
> lib/kobject_uevent.c is byte-identical to the audited 7.3 tree
> (sha256 bbcf120ea86f42c74dec10e255a8cd0b3034c9f34cd5bb911fd94015729dd076).
> Kernel config included CONFIG_NET_NS=y, CONFIG_INFINIBAND=y,
> CONFIG_INFINIBAND_USER_ACCESS=y, CONFIG_RDMA_RXE=y, CONFIG_DUMMY=y
> and CONFIG_KASAN=y. The kernel source was not modified to inject
> the race; only the IB/RXE configuration was enabled and a userspace
> reproducer was added.
No patch?
next prev parent reply other threads:[~2026-11-10 18:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4c7f9772.192e1.1a17d5c2ed5.Coremail.xuhx@hust.edu.cn>
[not found] ` <2026102727-data-sequel-ce41@gregkh>
2026-11-10 12:56 ` driver core: uevent: netns teardown frees uevent_sock while a tagged uevent is still being broadcast (UAF) 徐晗翔
2026-11-10 13:00 ` 徐晗翔
2026-11-10 18:48 ` Greg KH [this message]
2026-11-11 7:30 ` kernfs: kernfs_drain()'s fast-path decision reads the active count without acquire ordering -- on weakly-ordered architectures the forced ->release()/unmap can be skipped 徐晗翔
2026-11-11 13:41 ` Greg KH
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=2026111041-plasma-dreadlock-df34@gregkh \
--to=greg@kroah.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=xuhx@hust.edu.cn \
/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