CVE-2025-22068

What it actually does

Use-after-free in the ublk driver caused by ubq->canceling not being reliably observable from ublk_queue_rq() when the request queue is frozen, allowing uring_cmd operations to proceed after the associated structures have been released.

Why it matters to the business

Potential kernel memory corruption or privilege escalation on systems using the ublk block device driver, especially in container or virtualized environments; low exploitability reduces immediate risk but still requires patching of affected Linux kernels.

How an attack unfolds

An attacker with local access triggers queue freezing while uring_cmd operations are in flight; because the canceling flag is not set, ublk_queue_rq() dispatches a request that later completes against freed memory, leading to use-after-free. No public exploitation observed despite mentions of related Linux kernel privilege-escalation campaigns.

How to fix it

Upgrade to a kernel containing commit 7e3497d7dacb5aee69dd9be842b778083cae0e75 or later; rebuild and reboot with the fixed ublk driver. For listed Red Hat packages apply python-werkzeug and python3-werkzeug updates to 2.0.1-9.el8ost where applicable.

How to confirm the fix worked

Confirm the presence of commit 7e3497d7dacb5aee69dd9be842b778083cae0e75 in the running kernel source; verify ubq->canceling is set before queue freeze in code review or runtime tracing; test that uring_cmd operations are rejected cleanly when the queue is frozen.

Typical attack path

1. Obtain local code execution on a system with ublk enabled
2. Craft workload that freezes the request queue while uring_cmd requests are pending
3. Trigger dispatch path in ublk_queue_rq() after structures are released
4. Achieve memory corruption or escalation via the resulting use-after-free

How to detect it

Review kernel logs for ublk-related use-after-free warnings or oops messages around queue freeze events; inspect io_uring command completion paths for unexpected behavior; correlate with process activity using ublk devices.

What your security team should do

• Prioritize kernel updates on hosts using ublk or io_uring block devices
• Audit container runtimes and virtual machine images for vulnerable kernel versions
• Monitor EPSS and threat actor activity for any increase in exploit maturity
• Apply fixed versions listed for Red Hat OpenStack packages if present in the environment