CVE-2026-97618: io_uring/net: don't overconsume buffers when using MSG_TRUNC
In the Linux kernel, the following vulnerability has been resolved:
iouring/net: don't overconsume buffers when using MSGTRUNC
When a recv/recvmsg is issued with MSGTRUNC and the incoming packet is larger than the provided buffer, the net layer returns the full length of the packet rather than the number of bytes actually copied into the buffer. As a result, iouring advances more of the provided buffer ring than was actually filled. Use the actual filled region size to consume the buffer, but still return the full size to preserve MSGTRUNC semantics.
Take care with multishot, because that seems to already truncate the consumption based on the available payload size.
This was reported in https://github.com/axboe/liburing/issues/1619.
[axboe: fold in sizet unsigned fix]
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
An application must use io_uring receive operations with MSG_TRUNC, receive a packet larger than its supplied buffer, and use a provided buffer ring. Under those conditions, io_uring can consume more buffer-ring space than was actually filled.
What behavior indicates that a system or application may be affected?
Affected applications can show provided buffer-ring advancement that exceeds the amount of packet data copied into the buffer after an oversized MSG_TRUNC receive. The receive operation still reports the full packet length, which is expected MSG_TRUNC behavior; the incorrect behavior is the buffer consumption accounting.
Does this affect multishot receive operations in the same way?
The description notes that multishot handling already appears to truncate consumption based on available payload size. The fix specifically takes multishot behavior into account.