CVE-2026-52933

What it actually does

This flaw affects the Linux kernel io_uring polling path. A signed integer comparison in io_poll_get_ownership() can misinterpret poll_refs when the high-bit cancel flag is set, causing the value to appear negative and bypassing the intended slow path. In practical terms, cancellation/ownership state for io_uring poll requests can be handled incorrectly under specific timing conditions, potentially leading to race-condition behavior such as inconsistent request state, kernel instability, denial of service, or other memory-safety side effects depending on the surrounding kernel version and configuration.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local reliability and security risk from workloads or users able to exercise io_uring. The most likely operational consequence is system instability or denial of service, but kernel race-condition bugs can carry elevated concern because successful exploitation may affect the host operating system itself. Public exploitation is not currently indicated, EPSS is very low, and the issue is not listed in CISA KEV, so remediation should be handled through normal kernel patch cycles unless the environment allows untrusted local code execution, shared hosting, containers with broad kernel attack surface, or high-risk multi-tenant workloads.

How an attack unfolds

An attacker would need the ability to run code on a system that exposes the affected kernel io_uring functionality. They would create io_uring poll operations and manipulate cancellation or completion timing so that IO_POLL_CANCEL_FLAG is set in poll_refs. Because the kernel previously compared this signed value against the slow-path threshold, the cancel-flagged value could be treated as negative and fail the threshold check. Repeated attempts may trigger an incorrect ownership path or race window in poll request handling. Depending on kernel build, workload timing, and adjacent hardening, this may result in a kernel crash, task hang, resource leak, or potentially broader kernel memory corruption effects. There is no known public exploit maturity reported for this issue.

How to fix it

Apply a Linux kernel update that includes the fix for io_uring/poll: casting the atomic poll_refs value to unsigned before comparing it with IO_POLL_REF_BIAS in io_poll_get_ownership(). Because no fixed package versions were provided, use the relevant Linux distribution or kernel vendor advisory to identify the corrected kernel build and reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting container workloads that can exercise the host kernel attack surface, disabling or constraining io_uring where supported by policy or runtime controls, and applying standard kernel hardening such as seccomp profiles that block io_uring_setup/io_uring_enter for workloads that do not require them.

How to confirm the fix worked

Confirm the running kernel is a vendor build that includes the upstream fix for the io_uring poll_refs signed comparison. Validate both the installed kernel package and the active booted kernel, since Linux kernel updates generally require a reboot. Review distribution changelogs or source patches for the io_poll_get_ownership() change that casts atomic_read(&req->poll_refs) to unsigned int before comparing with IO_POLL_REF_BIAS. Where runtime mitigations are used, verify seccomp, container runtime, or workload policy blocks io_uring_setup and related io_uring syscalls for untrusted applications that do not need them.

Typical attack path

1. Obtain the ability to execute local code on a Linux system running an affected kernel.
2. Use io_uring interfaces to create poll requests against file descriptors or sockets.
3. Trigger cancellation and completion races so poll_refs has the high-bit cancel flag set.
4. Cause io_poll_get_ownership() to incorrectly skip the slow path because the signed comparison treats the flagged value as negative.
5. Repeat the race to induce unstable kernel behavior such as a crash, hang, or other unintended state transition.

How to detect it

Because this is a kernel logic/race-condition issue and no public exploit indicators are provided, detection should focus on evidence of attempted local abuse and resulting instability rather than a unique network signature. Review kernel logs, system journals, crash dumps, audit logs, and endpoint telemetry for unexplained kernel oopses, panics, soft lockups, hung tasks, or warnings involving io_uring, poll, cancellation, or task work. Hunt for unusual local processes making high volumes of io_uring_setup, io_uring_enter, and io_uring_register syscalls, especially from untrusted users, containers, CI jobs, temporary directories, or newly dropped binaries. On systems with auditd or eBPF syscall tracing, search for bursts of io_uring activity followed by process termination, service disruption, host reboot, or kernel error messages. If kernel crash dumps are available, inspect call traces for io_poll_get_ownership, io_uring poll cancellation paths, and related io_uring/poll functions.

• io_poll_get_ownership
• io_uring
• io_uring_setup
• io_uring_enter
• io_uring_register
• IO_POLL_CANCEL_FLAG
• IO_POLL_REF_BIAS
• kernel: BUG:
• kernel: WARNING:
• kernel: Oops:
• kernel panic
• soft lockup
• hung task
• blocked for more than
• Call Trace:
• io_poll
• io_uring/poll

What your security team should do

• Inventory Linux systems and container hosts that allow untrusted or semi-trusted local code execution.
• Prioritize patching multi-tenant servers, shared compute platforms, container hosts, CI/CD runners, developer workstations, and internet-facing services that execute user-supplied code.
• Update to a vendor kernel that includes the io_uring poll ownership fix and reboot to activate it.
• If patching is delayed, restrict io_uring syscalls for workloads that do not require them using seccomp, container runtime policies, or endpoint controls.
• Monitor for unexplained kernel crashes, soft lockups, task hangs, or io_uring-heavy local processes on unpatched systems.
• Track vendor advisories for exact fixed kernel versions because fixed package data was not provided in the input.
• Treat this as normal-to-moderate urgency in most environments due to low EPSS, no KEV listing, and no known exploit maturity, but raise priority where local untrusted code execution is common.