CVE-2026-98815

What the bug is

Sashiko bot reported a potential problem for the cdev lifetime in [0] - the code there is heavily based on the NVMe code. Currently the NS head .open and .release file_operations methods take and put a reference to the nvme_ns_head to ensure that this structure does not disappear while we open fds for that cdev. In multipath mode, when we teardown the NS head, we call nvme_cdev_del() -> cdev_device_del() -> cdev_del(). However after cdev_del() returns, cdevs already open will remain and their fops will still be callable. As such, we can still reference the cdev after the nvme_ns_head reference count drops to 0 (and is freed). This can be shown with an application which delays between opening the cdev and issuing the ioctl while the NS head is being torn down: # ./ioctl_file /dev/ng1n1 & # waiting 10 seconds .... # ./ini_nvme_teardown.sh [ 21.221718] nvme nvme1: Removing ctrl: NQN "nvme-test-target" [ 21.274609] nvme nvme2: Removing ctrl: NQN "nvme-test-target" # now going to issue ioctl .... [ 26.549285] ================================================================== [ 26.550841] BUG: KASAN: slab-use-after-free in cdev_put.part.0+0x3d/0x40 [ 26.552352] Read of size 8 at addr ffff88811e7fa170 by task ioctl_file/237 [ 26.553805] [ 26.554227] CPU: 3 UID: 0 PID: 237 Comm: ioctl_file Not tainted 7.2.0-rc1-00004-g6852a10e32d4 #921 PREEMPT(lazy) [ 26.554236] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 26.554241] Call Trace: [ 26.554245] <TASK> [ 26.554248] dump_stack_lvl+0x68/0xa0 [ 26.554266] print_report+0x10d/0x5d0 [ 26.554276] ? __virt_addr_valid+0x21d/0x3f0 [ 26.554287] ? cdev_put.part.0+0x3d/0x40 [ 26.554292] kasan_report+0x96/0xd0 [ 26.554300] ? cdev_put.part.0+0x3d/0x40 [ 26.554307] cdev_put.part.0+0x3d/0x40 [ 26.554313] __fput+0x7bc/0xa70 [ 26.554322] fput_close_sync+0xd8/0x190 [ 26.554328] ? __pfx_fput_close_sync+0x10/0x10 [ 26.554337] __x64_sys_close+0x79/0xd0 [ 26.554344] do_syscall_64+0x117/0x6b0 [ 26.554351] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 26.554358] RIP: 0033:0x7f938c067727 [ 26.554364] Code: 48 89 fa 4c 89 df e8 28 ad 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5bf [ 26.554369] RSP: 002b:00007fff49f05980 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 [ 26.554376] RAX: ffffffffffffffda RBX: 00007f938bfd7780 RCX: 00007f938c067727 [ 26.554380] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [ 26.554383] RBP: 00007fff49f05a10 R08: 0000000000000000 R09: 0000000000000000 [ 26.554386] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 26.554389] R13: 00007fff49f05b40 R14: 00007f938c207000 R15: 000055c148471d78 [ 26.554397] </TASK> [ 26.554399] [ 26.575612] Allocated by task 100: [ 26.575871] kasan_save_stack+0x24/0x50 [ 26.576157] kasan_save_track+0x14/0x30 [ 26.576418] __kasan_kmalloc+0x7f/0x90 [ 26.576668] __kmalloc_noprof+0x281/0x6c0 [ 26.576938] nvme_alloc_ns+0x7f7/0x3170 [ 26.577206] nvme_scan_ns+0x508/0x880 [ 26.577449] async_run_entry_fn+0x8c/0x350 [ 26.577723] process_scheduled_works+0xb6f/0x1a00 [ 26.578034] worker_thread+0x4ad/0xb40 [ 26.578283] kthread+0x34f/0x450 [ 26.578501] ret_from_fork+0x563/0x800 [ 26.578752] ret_from_fork_asm+0x1a/0x30 [ 26.579012] [ 26.579124] Freed by task 237: [ 26.579335] kasan_save_stack+0x24/0x50 [ 26.579596] kasan_save_track+0x14/0x30 [ 26.579855] kasan_save_free_info+0x3a/0x60 [ 26.580131] __kasan_slab_free+0x43/0x70 [ 26.580388] kfree+0x321/0x500 [ 26.580591] nvme_ns_head_chr_release+0x39/0x50 [ 26.580883] __fput+0x352/0xa70 [ 26.581095] fput_close_sync+0xd8/0x190 [ 26.581350] __x64_sys_close+0x79/0xd0 [ 26.581595] do_syscall_64+0x117/0x6b0 [ 26.581842] entry_SYSCAL ---truncated---

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/nvme/host/core.c
drivers/nvme/host/multipath.c

What this is

NVM EXPRESS DRIVERMAINTAINERS section matched on drivers/nvme/host/ · linux-nvme@lists.infradead.org · Supported

Kernel module

nvme_core

Check it on the machine

grep -w CONFIG_NVME_CORE /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w nvme_core

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

• bookworm, trixie, forky, sidb

b

built in on some flavours, a module on others

Build switch

CONFIG_NVME_CORE

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-10-18 (today)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

not scored

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/nvme

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
0	7.2.10	98b09ad79344
0	7.3	9952f3882ecb