Linux kernel io_uring: unchecked user address overflow in io_pin_pages during ring setup

CVSS 5.5CVE-2024-53187Kernel, userspace & hypervisorcurated

Impact

io_pin_pages() added a size to an attacker-controlled uaddr without checking for overflow, so a crafted io_uring_setup() reaches a WARN in the memory-mapping path (syzkaller trace in the record). Any unprivileged local process can call io_uring_setup, which makes this the broadest of the kernel issues in this batch: on a shared GPU node, a tenant pod with default seccomp that permits io_uring can produce kernel warnings and, on panic_on_warn fleets, take the whole node down. The record reports availability impact only, with no disclosure or privilege escalation.

Who can reach it

Local, unprivileged: any process able to call io_uring_setup, including an ordinary tenant container unless io_uring is blocked by seccomp.

What to do

Update to a stable kernel with the overflow check in io_pin_pages (linked commits) and reboot the node. Where rebooting the fleet now is not viable, block io_uring syscalls in the container seccomp profile (or set kernel.io_uring_disabled where available) for untrusted workloads. No vendor fixed-version string is in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-53187 https://git.kernel.org/stable/c/f1938217aee05be1c1dc53f581a3c353d033b508 https://git.kernel.org/stable/c/1a0aecabff72a95d240e6d7645949bfe0620dcd7 https://git.kernel.org/stable/c/0c0a4eae26ac78379d0c1db053de168a8febc6c9

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.