CVE-2022-3169

What it actually does

Consecutive NVME_IOCTL_RESET and NVME_IOCTL_SUBSYS_RESET ioctls on an NVMe device file trigger a PCIe link disconnect, resulting in denial of service.

Why it matters to the business

Systems relying on NVMe storage may experience sudden loss of device connectivity, causing application outages and requiring manual intervention or reboot to restore service.

How an attack unfolds

An attacker with local access opens the NVMe device file and issues the two reset ioctls in quick succession, forcing the driver to disconnect the PCIe link and rendering the storage unavailable.

How to fix it

Apply the latest available Linux kernel updates from the distribution vendor; restrict unprivileged access to NVMe device files via udev rules or device permissions until patches are deployed.

How to confirm the fix worked

Verify the running kernel version against vendor advisories; attempt to reproduce the consecutive reset sequence on a test system and confirm the PCIe link remains stable.

Typical attack path

1. Obtain local user access on a Linux system with NVMe storage
2. Locate and open the NVMe device file under /dev
3. Invoke NVME_IOCTL_RESET followed immediately by NVME_IOCTL_SUBSYS_RESET
4. Observe PCIe link drop and resulting storage outage

How to detect it

Review kernel logs for NVMe driver messages indicating consecutive reset requests or unexpected PCIe link disconnection; correlate with user processes issuing ioctls on NVMe device files.

• nvme nvme0: Removing nvme device
• nvme nvme0: failed to set queue count
• nvme: detected device in failed state after reset

What your security team should do

• Prioritize kernel updates across all affected Linux distributions
• Limit local user access to NVMe character devices
• Monitor kernel logs for NVMe reset or link-down events
• Test patches in a staging environment before broad rollout