CVE-2026-80584: s390/qeth: validate user buffer length in SNMP and ARP query ioctls
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: validate user buffer length in SNMP and ARP query ioctls
qethsnmpcommand() and qethl3arpquery() allocate a buffer sized by a user-supplied length (udatalen) without checking a lower bound, then set udataoffset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with
if ((udatalen - udataoffset) < len)
Both fields are u32, so a udatalen smaller than udataoffset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udatalen of 0 also yields ZEROSIZEPTR from kzalloc(), which the existing NULL check does not catch.
Reject buffers smaller than udataoffset before allocating, so the callback subtraction can no longer underflow.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to trigger this issue?
An attacker needs the ability to issue the affected SNMP or ARP query ioctls to the s390 qeth driver and control the user-supplied buffer length. Supplying a length smaller than the fixed reply-data offset can cause an unsigned underflow and an out-of-bounds write.
Are zero-length buffers affected?
Yes. A user-supplied length of zero can cause kzalloc() to return ZERO_SIZE_PTR, which is not caught by the existing NULL check before later processing.
What is the relevant mitigation if an update cannot be applied immediately?
Restrict access to the affected qeth SNMP and ARP query ioctls to trusted users or processes. The flaw is triggered through attacker-controlled ioctl buffer lengths.
How does the fix prevent exploitation?
The fix rejects user buffers smaller than the required fixed offset before allocation. This prevents the callback's udata_len minus udata_offset calculation from underflowing and avoids allocating a buffer that is too small.