CVE-2022-48790

What it actually does

Race condition during NVMe controller reset allows async event submission after admin queue teardown, resulting in use-after-free of queue resources.

Why it matters to the business

Systems using NVMe storage over TCP may experience kernel instability or crashes during controller resets, leading to unplanned downtime and potential data access loss on affected Linux deployments.

How an attack unfolds

An attacker with local access triggers repeated controller resets while AEN handling races with teardown; the driver submits an AER after the queue socket is released, causing the use-after-free.

How to fix it

Update the Linux kernel to commit a25e460fbb0340488d119fb2e28fe3f829b7417e or later stable releases containing the state check before AER submission.

How to confirm the fix worked

Verify kernel source contains the ctrl state check in submit_async_event path and confirm running kernel version includes the referenced commit; test controller reset sequences under load.

Typical attack path

1. Trigger NVMe controller reset via reset_ctrl_work
2. Flush async_event_work during nvme_stop_ctrl
3. Receive and schedule AEN handling from controller
4. Teardown admin queue releasing queue socket
5. Process AEN and submit new AER without state check
6. Driver sends command to freed queue causing UAF

How to detect it

Review kernel logs for NVMe reset sequences followed by use-after-free oops or panic messages; inspect dmesg and journalctl for AER submission after queue release indicators.

What your security team should do

• Prioritize kernel updates on all systems using nvme-tcp
• Monitor for controller reset events in NVMe logs
• Apply the fix in custom or downstream kernel builds
• Test reset handling in staging environments before production rollout