CVE-2022-3910

What it actually does

Improper reference count decrement in io_uring's io_msg_ring handler for fixed files triggers a use-after-free in the Linux kernel, enabling local attackers to corrupt kernel memory and escalate privileges.

Why it matters to the business

Local attackers can obtain full root access on affected Linux systems, risking complete host compromise, data theft, or persistence; low urgency given age, low EPSS, and lack of known exploitation or ransomware use, though high prevalence of Linux kernels amplifies exposure across servers and containers.

How an attack unfolds

An attacker with local shell access registers fixed files in an io_uring ring, invokes io_msg_ring to force an erroneous io_fput_file call that drops the refcount, then reuses the freed object via kernel heap manipulation to overwrite credentials or hijack execution flow for privilege escalation.

How to fix it

Upgrade the Linux kernel to include commit fc7222c3a9f56271fba02aabbfbae999042f1679 or any later mainline or distribution backport that resolves the io_uring fixed-file reference counting error.

How to confirm the fix worked

Verify the running kernel contains the referenced commit or equivalent patch; confirm via kernel build logs or git history that io_fput_file is no longer called on fixed files from io_msg_ring; run regression tests exercising io_uring fixed-file paths.

Typical attack path

1. Obtain local unprivileged shell on target Linux host
2. Initialize io_uring instance and register fixed files
3. Issue io_msg_ring operation to trigger improper reference count update
4. Reuse freed kernel object to corrupt process credentials or function pointers
5. Execute payload that grants root shell or installs persistent backdoor

How to detect it

Review kernel audit logs, dmesg, and syslog for unexpected use-after-free warnings or oops involving io_uring; correlate with sudden uid changes or new root processes originating from non-root users; inspect io_uring related syscalls in strace or eBPF traces from suspected accounts.

What your security team should do

• Prioritize kernel upgrades on all internet-facing or multi-tenant Linux systems within standard change windows
• Enable kernel hardening features such as lockdown mode and unprivileged_userns_clone=0 where io_uring is not required
• Audit local user accounts and restrict interactive shells on production hosts
• Monitor kernel logs and auditd for anomalous io_uring or credential modification events