CVE-2022-48788

What it actually does

Race condition in nvme-rdma error recovery work permits use-after-free when async_event_work state checks race with controller RESETTING transition, allowing memory corruption during admin queue destruction.

Why it matters to the business

Linux systems using NVMe over RDMA storage face risk of local privilege escalation or kernel crashes that can interrupt storage services and require emergency patching across fleets.

How an attack unfolds

Local attacker induces NVMe RDMA transport errors while async event work is pending; the flawed state check allows submit_async_event to run after queue teardown begins, dereferencing freed memory for corruption or code execution.

How to fix it

Upgrade the Linux kernel to the version containing commit 5593f72d1922403c11749532e3a0aa4cf61414e9 or any later stable release that resolves the nvme-rdma race.

How to confirm the fix worked

Confirm the running kernel source contains commit 5593f72d1922403c11749532e3a0aa4cf61414e9; exercise nvme-rdma error paths in a test environment to verify no use-after-free occurs.

Typical attack path

1. Obtain local user access on target Linux host
2. Trigger NVMe RDMA controller error conditions
3. Race async_event_work against error_recovery handler
4. Leverage freed memory object for privilege escalation

How to detect it

Inspect kernel logs and dmesg for nvme_rdma error_recovery or async_event_work crashes; correlate with storage subsystem state changes around the time of any kernel oops or panic.

What your security team should do

• Apply the referenced kernel commit or newer release on all NVMe RDMA hosts without delay
• Limit local unprivileged access on storage servers until patches are deployed
• Review kernel logs for prior nvme_rdma crashes as part of incident review