CVE-2022-47946

What it actually does

Use-after-free vulnerability in io_sqpoll_wait_sq within the io_uring subsystem that permits an attacker to trigger a kernel crash via skipped finish_wait operations.

Why it matters to the business

Local users on affected Linux systems can cause repeated kernel panics leading to denial of service, system downtime, and potential disruption of services relying on io_uring for high-performance I/O.

How an attack unfolds

An attacker with local access forks a process that engages io_uring sqpoll, then rapidly terminates it to hit the use-after-free condition before proper cleanup occurs, resulting in a kernel panic.

How to fix it

Upgrade the Linux kernel to version 5.10.155 or a later maintained series where the io_sqpoll_wait_sq implementation was substantially revised; apply vendor-supplied patches if available for distribution kernels.

How to confirm the fix worked

Verify the running kernel version is at least 5.10.155; attempt reproduction of the fork-and-terminate sequence in a test environment and confirm absence of kernel oops or panic referencing io_uring.

Typical attack path

1. Obtain local shell access on a vulnerable 5.10.x kernel
2. Execute code that initializes an io_uring instance with sqpoll enabled
3. Fork a child process performing I/O operations
4. Immediately terminate the child to trigger the race condition
5. Observe kernel crash due to use-after-free

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops or panic messages mentioning io_sqpoll_wait_sq or io_uring; correlate with process creation/termination events around the time of crashes.

• io_sqpoll_wait_sq
• finish_wait
• kernel panic.*io_uring

What your security team should do

• Prioritize kernel upgrades on all systems running 5.10.x before 5.10.155
• Restrict untrusted local user access where possible until patched
• Monitor kernel logs for io_uring related crashes as an interim detection measure
• Test io_uring dependent workloads after patching to ensure stability