CVE-2022-50552
📋 TL;DR
A use-after-free vulnerability in the Linux kernel's block multi-queue (blk-mq) subsystem allows local attackers to cause kernel panics or potentially execute arbitrary code. The race condition occurs during elevator scheduler switching when reinitializing hardware queues, leading to NULL pointer dereferences. This affects Linux systems using the blk-mq subsystem with NVMe or similar storage controllers.
💻 Affected Systems
- Linux kernel
⚠️ Risk & Real-World Impact
Worst Case
Kernel panic leading to system crash and denial of service, with potential for privilege escalation to kernel-level code execution.
Likely Case
System crash and denial of service when storage controllers are reset or reconfigured.
If Mitigated
Minimal impact if systems are patched or don't use affected storage configurations.
🎯 Exploit Status
Requires local access and ability to trigger storage controller resets or queue reinitialization to exploit the race condition.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Patches available in stable kernel trees via git commits: 63a681bcc32a, 8237c01f1696, c478b3b2900f
Vendor Advisory: https://git.kernel.org/stable/c/63a681bcc32a43528ce0f690569f7f48e59c3963
Restart Required: Yes
Instructions:
1. Update Linux kernel to version containing the fix. 2. Check with distribution vendor for backported patches. 3. Reboot system after kernel update.
🔧 Temporary Workarounds
Avoid storage controller resets
linuxPrevent operations that trigger NVMe controller resets or hardware queue reinitialization
🧯 If You Can't Patch
- Restrict local access to prevent malicious users from triggering storage operations
- Monitor for storage controller resets and investigate unusual activity
🔍 How to Verify
Check if Vulnerable:
Check kernel version and compare with patched versions from distribution vendor. Examine if system uses NVMe or similar storage with blk-mq.Check Version:
uname -rVerify Fix Applied:
Verify kernel version includes the fix commits or is newer than patched versions. Check dmesg for absence of related panic messages.📡 Detection & Monitoring
Log Indicators:
- Kernel panic messages mentioning 'kyber_has_work', 'blk_mq_run_work_fn', or NULL pointer dereferences in storage context
- NVMe controller reset logs followed by crashes
SIEM Query:
source="kernel" AND ("kyber_has_work" OR "blk_mq_run_work_fn" OR "NULL pointer dereference" AND "nvme")