CVE-2026-23148

What it actually does

Race condition in nvmet_bio_done() permits nvmet_req_bio_put() to invoke bio_uninit() on the inline_bio after nvmet_req_complete() triggers re-submission via queue_response, leaving bi_blkg NULL when the re-queued bio reaches blk_cgroup_bio_start() inside submit_bio_noacct_nocheck().

Why it matters to the business

Systems exposing NVMe over Fabrics target functionality can suffer unexpected kernel crashes and service interruption; widespread Linux kernel deployment increases operational risk until patched releases are applied.

How an attack unfolds

An attacker with network access to submit NVMe commands triggers repeated bio completion and re-queuing paths in nvmet; the window between nvmet_req_complete() and the subsequent nvmet_req_bio_put() allows the same inline_bio to be re-submitted while bi_blkg has already been cleared, resulting in the NULL dereference crash.

How to fix it

Upgrade the Linux kernel to version 6.12.69 or apply commit ee10b06980acca1d46e0fa36d6fb4a9578eab6e4; rebuild and reboot affected hosts with the patched kernel image.

How to confirm the fix worked

Confirm running kernel version is at least 6.12.69 or contains commit ee10b06980acca1d46e0fa36d6fb4a9578eab6e4; attempt to reproduce the original race with targeted NVMe command sequences and verify absence of the NULL dereference oops.

Typical attack path

1. Submit NVMe read/write commands to nvmet target
2. Force bio completion that invokes nvmet_bio_done()
3. queue_response callback re-queues the request reusing inline_bio
4. nvmet_req_bio_put() runs after re-submission and calls bio_uninit()
5. Re-submitted bio reaches blk_cgroup_bio_start() and dereferences NULL bi_blkg

How to detect it

Search kernel logs and crash dumps for oops traces containing blk_cgroup_bio_start, submit_bio_noacct_nocheck, nvmet_bdev_execute_rw, and nvmet_bio_done; correlate with process_one_work and worker_thread entries.

• BUG: kernel NULL pointer dereference, address: 0000000000000028
• RIP: 0010:blk_cgroup_bio_start+0x10/0xd0
• Call Trace: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370
• nvmet_bio_done

What your security team should do

• Prioritize kernel upgrades on all hosts exposing nvmet target functionality
• Apply the fix within standard change windows given the 254-day exposure window
• Add kernel crash monitoring for nvmet-related oops to detect attempted exploitation
• Review downstream dependent packages and rebuild any custom kernels containing nvmet