NetBSD Problem Report #60104

From www@netbsd.org  Thu Mar 19 05:02:02 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 308051A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 19 Mar 2026 05:02:02 +0000 (UTC)
Message-Id: <20260319050201.0E81E1A923A@mollari.NetBSD.org>
Date: Thu, 19 Mar 2026 05:02:01 +0000 (UTC)
From: imuwoto@gmail.com
Reply-To: imuwoto@gmail.com
To: gnats-bugs@NetBSD.org
Subject: vnd use-after-free bug
X-Send-Pr-Version: www-1.0
X-From4GNATS: "imuwoto@gmail.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60104
>Category:       kern
>Synopsis:       vnd use-after-free bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 19 05:05:00 +0000 2026
>Originator:     YAMAMOTO Takashi
>Release:        -current
>Organization:
>Environment:
amd64
>Description:
vndopen seems to assume "sc" is stable.
actually it can get destroyed by other thread (eg. vndclose)
while it's sleeping. (eg. in vndlock)

see the following crash. 0xfffffffffffffff0 is a destroyed mutex.

[ 4029.2975547] uvm_fault(0xffffffff81b19ba0, 0xfffffffffffff000, 1) -> e
[ 4029.2975547] fatal page fault in supervisor mode
[ 4029.2975547] trap type 6 code 0 rip 0xffffffff80df9122 cs 0x8 rflags 0x10286 cr2 0xfffffffffffffff0 ilevel 0 rsp 0xffffbc00ca2fea70
[ 4029.2975547] curlwp 0xffffa29d08751400 pid 13118.13865 lowest kstack 0xffffbc00ca2fa2c0
[ 4029.3161299] panic: trap
[ 4029.3161299] cpu0: Begin traceback...
[ 4029.3161299] vpanic() at netbsd:vpanic+0x189
[ 4029.3161299] panic() at netbsd:panic+0x3c
[ 4029.3161299] trap() at netbsd:trap+0xb35
[ 4029.3161299] --- trap (number 6) ---
[ 4029.3161299] mutex_oncpu() at netbsd:mutex_oncpu+0x20
[ 4029.3267109] mutex_vector_enter() at netbsd:mutex_vector_enter+0xbb
[ 4029.3431144] vndopen() at netbsd:vndopen+0xfe
[ 4029.3431144] cdev_open() at netbsd:cdev_open+0x135
[ 4029.3431144] spec_open() at netbsd:spec_open+0x215
[ 4029.3431144] VOP_OPEN() at netbsd:VOP_OPEN+0x3e
[ 4029.3809844] vn_open() at netbsd:vn_open+0x21c
[ 4029.3809844] do_open() at netbsd:do_open+0xc7
[ 4029.3809844] do_sys_openat() at netbsd:do_sys_openat+0x72
[ 4029.3809844] sys_openat() at netbsd:sys_openat+0x24
[ 4029.3809844] syscall() at netbsd:syscall+0x9d
[ 4029.3809844] --- syscall (number 468) ---
[ 4029.3912636] netbsd:syscall+0x9d:
[ 4029.3912636] cpu0: End traceback...

>How-To-Repeat:
on my qemu/nvmm vm with 2 vcpus,

# mkdir dev
# cd dev
# cp /dev/MAKEDEV* .
# ./MAKEDEV all
# zpool import -d .

note: zpool import performs threaded access to the device files.

>Fix:
use device_lookup_acquire/config_attach_pseudo_acquire ?

Home	PR Database Search