Linux Kernel up to 7.2.9 nvme nvme_cdev_del use after free

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 8.4 | $0-$5k | 2.73- |
Summary
A vulnerability was found in Linux Kernel up to 7.2.9. It has been classified as very critical. Impacted is the function nvme_cdev_del of the component nvme. The manipulation leads to use after free.
This vulnerability is documented as CVE-2026-98815. The attack needs to be performed locally. There is not any exploit available.
Upgrading the affected component is recommended.
Details
A vulnerability was found in Linux Kernel up to 7.2.9. It has been rated as very critical. This issue affects the function nvme_cdev_del of the component nvme. The manipulation with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: nvme: fix cdev lifetime 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---
It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-98815 since 09/25/2026. The exploitation is known to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/18/2026).
Upgrading to version 7.2.10 or 7.3-rc1 eliminates this vulnerability. Applying the patch 98b09ad7934482e64db4b4477d91e3bbf43adf4c/9952f3882ecba709092379b71e02b09762b26f96 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Product
Type
Vendor
Name
Version
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 8.8VulDB Meta Temp Score: 8.4
VulDB Base Score: 8.8
VulDB Temp Score: 8.4
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Use after freeCWE: CWE-416 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: No
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 7.2.10/7.3-rc1
Patch: 98b09ad7934482e64db4b4477d91e3bbf43adf4c/9952f3882ecba709092379b71e02b09762b26f96
Timeline
09/25/2026 CVE reserved10/18/2026 Advisory disclosed
10/18/2026 VulDB entry created
10/18/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-98815 (🔒)
GCVE (CVE): GCVE-0-2026-98815
GCVE (VulDB): GCVE-100-421811
Entry
Created: 10/18/2026 18:04Changes: 10/18/2026 18:04 (59)
Complete: 🔍
Cache ID: 216::103
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.