Bug 2492097 (CVE-2026-52933)

Summary: CVE-2026-52933 kernel: io_uring/poll: fix signed comparison in io_poll_get_ownership()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: akito5623, rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `io_uring/poll` component. A logic error exists in the `io_poll_get_ownership()` function due to an incorrect signed comparison. This flaw prevents the necessary slowpath from being triggered when the `IO_POLL_CANCEL_FLAG` is set, potentially leading to unexpected behavior or resource mismanagement within the kernel.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-24 08:01:51 UTC
In the Linux kernel, the following vulnerability has been resolved:

io_uring/poll: fix signed comparison in io_poll_get_ownership()

io_poll_get_ownership() uses a signed comparison to check whether
poll_refs has reached the threshold for the slowpath:

    if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS))

atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG
(BIT(31)) is set in poll_refs, the value becomes negative in
signed arithmetic, so the >= 128 comparison always evaluates to
false and the slowpath is never taken.

Fix this by casting the atomic_read() result to unsigned int
before the comparison, so that the cancel flag is treated as a
large positive value and correctly triggers the slowpath.

Comment 1 Mauro Matteo Cascella 2026-06-24 12:41:40 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062433-CVE-2026-52933-815c@gregkh/T

Comment 5 Akiyoshi Kurita 2026-08-26 02:54:38 UTC
FYI, a public exploit and demonstration for CVE-2026-53360 are now available.

Public PoC / exploit:
https://github.com/0xCyberstan/CVE-2026-53360-POC

Demo video:
https://x.com/nebusecurity/status/2092431446824878130

Relevant stable kernel fixes / reference patches:

RHEL 9 reference (6.1.175 backport):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=81bf96b0abbfa4cd47ea32e12596aed3855fb2f3

RHEL 10 reference (6.12.86 backport):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc47043f3d9af3efa407665b47f8378ec691ba18

Mitigation / exposure note:
Since io_uring is disabled by default on RHEL, practical exposure may be limited unless io_uring has been explicitly enabled.

Red Hat CVE page:
https://access.redhat.com/security/cve/cve-2026-53360

Comment 6 Akiyoshi Kurita 2026-08-26 03:23:39 UTC
Correction to Comment 5:

Comment 5 incorrectly referenced CVE-2026-53360 and included the wrong exploit URL.

The correct information for CVE-2026-52933 is as follows:

FYI, a public exploit and demonstration for CVE-2026-52933 are now available.

Red Hat CVE page:
https://access.redhat.com/security/cve/cve-2026-52933

Public exploit:
https://github.com/NebuSec/CyberMeowfia/tree/main/security-research/Linux-CVE-2026-52933-Fedora-6.19.10-300

Demo video:
https://x.com/nebusecurity/status/2092431446824878130

Relevant stable kernel fixes / reference patches:

RHEL 9 reference (6.1.175 backport):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=81bf96b0abbfa4cd47ea32e12596aed3855fb2f3

RHEL 10 reference (6.12.86 backport):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc47043f3d9af3efa407665b47f8378ec691ba18

Mitigation / exposure note:
Since io_uring is disabled by default on RHEL, practical exposure may be limited unless io_uring has been explicitly enabled.

Please disregard the incorrect CVE-2026-53360 references in Comment 5.