CVE-2022-49001

What it actually does

Race condition in RISC-V vmap stack overflow detection where multiple harts can concurrently access the shared shadow stack before get_overflow_stack is called, leading to use-after-free or corruption.

Why it matters to the business

System instability, kernel panics, or memory corruption on RISC-V Linux deployments under concurrent overflow conditions, increasing downtime risk for affected hardware.

How an attack unfolds

Attacker forces simultaneous vmap stack overflows on multiple CPU cores on RISC-V; the lack of atomic protection allows concurrent shadow stack use, enabling potential memory corruption or denial of service.

How to fix it

Apply kernel patch from commit ac00301adb19df54f2eae1efc4bad7447c0156ce; update to a fixed Linux kernel version containing the spin_shadow_stack atomic variable.

How to confirm the fix worked

Confirm presence of atomic swap logic for spin_shadow_stack in the RISC-V overflow handler and test under multi-core overflow scenarios.

Typical attack path

1. Trigger vmap stack overflow on multiple harts concurrently
2. Exploit unprotected shared shadow stack access
3. Induce kernel panic or memory corruption

How to detect it

Review kernel panic logs and dmesg output for RISC-V stack overflow events; check for concurrent hart activity during overflow handling.

What your security team should do

• Prioritize kernel upgrades on all RISC-V systems within 30 days
• Monitor kernel logs for stack overflow panics
• Test patched kernels in staging before production rollout