CVE-2026-31774

What it actually does

CVE-2026-31774 is a Linux kernel memory-safety flaw in the io_uring network send/receive path. A 32-bit userspace-supplied length field can be copied into a signed integer and overflow when the value is greater than INT_MAX. The resulting negative length is later converted to a very large unsigned size, bypassing expected buffer-length clamping and allowing io_bundle_nbufs() to iterate beyond the allocated iovec array. The immediate impact is a slab out-of-bounds read from the kmalloc-64 slab. Because exploitation requires local code execution and low privileges, the main risks are local information disclosure from kernel memory and kernel instability or denial of service. The published CVSS score is 7.1, reflecting local attack requirements but high confidentiality and availability impact.

Why it matters to the business

An attacker who already has the ability to run code on a Linux system could use this flaw to crash affected systems or potentially read sensitive kernel memory. This can disrupt workloads, degrade host reliability, and increase risk in multi-user, shared hosting, container, CI/CD, and compute environments where untrusted or semi-trusted local users can execute code. The EPSS score is currently very low and there is no known CISA KEV listing or ransomware association, so broad active exploitation is not indicated; however, kernel vulnerabilities should still be prioritized on systems that allow local shell access, container workloads, or untrusted code execution.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host, such as through a shell account, compromised application process, container escape precondition, or malicious workload. They then create io_uring operations that exercise the network send or receive path and submit an SQE with an intentionally oversized length value greater than INT_MAX, such as 0xffffffff. In vulnerable kernels, this value overflows when stored in a signed integer, becomes negative, and then is later interpreted as an extremely large unsigned length. That incorrect length prevents normal clamping of selected ring buffers and causes io_bundle_nbufs() to walk past the allocated iovec entries. Depending on kernel configuration, memory layout, and runtime protections, this may expose adjacent kernel slab memory to the attacker or trigger a kernel fault, panic, or service outage. No mature public exploit is reported in the supplied data, and exploitation is local rather than remote.

How to fix it

Upgrade affected Linux kernels to a vendor build that includes the upstream fix rejecting negative send/receive lengths in io_sendmsg_prep() and io_recvmsg_prep(). Because no exact fixed versions were provided, use the relevant distribution or appliance vendor advisory for the kernel package version that contains the CVE-2026-31774 fix. Where immediate patching is not possible, reduce exposure by limiting local code execution, restricting untrusted shell access, isolating multi-tenant workloads, and applying container and sandbox hardening. If operationally feasible, restrict or disable io_uring for untrusted workloads using distribution-supported controls, seccomp profiles, container runtime policies, or LSM-based policy. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a vendor release containing the fix. Use commands such as uname -a, package-manager queries, and vendor advisory mapping to verify the active kernel version. Validate that hosts have been rebooted after the patched kernel was installed. Review whether untrusted workloads can invoke io_uring-related syscalls such as io_uring_setup and io_uring_enter; if mitigation policies are used, test that those syscalls are blocked or restricted for the intended users, containers, or services. For source-based validation, confirm the kernel tree rejects SQE length values that overflow signed send/receive request length handling in io_sendmsg_prep() and io_recvmsg_prep().

Typical attack path

1. Gain local ability to execute code on an affected Linux system.
2. Create or access a socket path that can be used with io_uring network send or receive operations.
3. Initialize an io_uring instance and prepare send or receive SQEs using the bundled buffer path.
4. Set the SQE length field to a value greater than INT_MAX, commonly 0xffffffff, to trigger signed integer overflow.
5. Submit the crafted io_uring request with io_uring_enter().
6. Cause the kernel to propagate the invalid negative length into later unsigned length calculations.
7. Trigger io_bundle_nbufs() to read beyond the allocated iovec array.
8. Observe kernel memory disclosure behavior, process failure, kernel warning, or system crash depending on protections and exploitation reliability.

How to detect it

Detection should focus on evidence of attempted local exploitation and resulting kernel faults. Review kernel logs, system journal, crash dumps, kdump/vmcore artifacts, audit logs, and EDR telemetry for io_uring activity followed by slab out-of-bounds warnings, KASAN reports, kernel oopses, panics, or call traces referencing io_bundle_nbufs and the io_uring network receive/send path. On systems with auditd or eBPF syscall telemetry, look for unusual or repeated io_uring_setup and io_uring_enter activity from untrusted users, containers, short-lived binaries, or processes that do not normally use io_uring. If KASAN or debug kernels are deployed, the strongest evidence is a slab-out-of-bounds report in io_bundle_nbufs. In production kernels without KASAN, evidence may appear only as kernel oops, general protection fault, panic, unexplained host reboot, or process termination temporally associated with io_uring syscalls. There are no supplied named threat actors, campaigns, or ransomware use; absence of these indicators does not rule out local proof-of-concept testing or opportunistic abuse.

• BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs
• slab-out-of-bounds in io_bundle_nbufs
• io_bundle_nbufs+0x128/0x160
• io_recv_finish+0x117/0xe20
• io_recv+0x2db/0x1160
• Read of size 8 at addr
• kmalloc-64 slab
• Call Trace:
• io_bundle_nbufs
• io_recv_finish
• io_recvmsg_prep
• io_sendmsg_prep
• io_uring_setup
• io_uring_enter

What your security team should do

• Prioritize patching internet-facing, shared, multi-user, container-hosting, CI/CD runner, build farm, and high-density compute systems where untrusted local code may execute.
• Track Linux distribution advisories and kernel package updates for this CVE, then deploy the fixed kernel and reboot affected systems.
• Inventory systems where io_uring is available to untrusted workloads and apply seccomp, container runtime, or LSM restrictions where patching is delayed.
• Monitor kernel logs for slab out-of-bounds, KASAN, panic, or call traces involving io_bundle_nbufs, io_recv_finish, io_recv, io_sendmsg_prep, or io_recvmsg_prep.
• Treat suspicious local crashes involving io_uring network operations as potential exploitation attempts, especially on shared systems.
• Because EPSS is low, not KEV-listed, and exploit maturity is reported as none, use risk-based prioritization rather than emergency internet-wide response, but do not defer patching on multi-tenant Linux hosts.