CVE-2026-98394: af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer.
afunix: Return immediately when manageoob() returns NULL for 0-length buffer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What conditions are required to trigger the busy-wait?
A blocking UNIX-domain stream socket receive must be called with a zero-length buffer and MSG_PEEK, while the last queued socket buffer is an MSG_OOB buffer.
Is a non-blocking receive affected?
The described busy-wait condition applies when recv() is blocking. The expected behavior for a zero-length receive is to return 0 immediately, regardless of blocking or non-blocking mode.
What is the practical impact?
Under the stated socket and receive conditions, unix_stream_read_generic() can busy-wait rather than returning immediately, potentially consuming CPU until the queue state changes.