Description

In the Linux kernel, the following vulnerability has been resolved: s390/qeth: validate user buffer length in SNMP and ARP query ioctls qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-26T15:17:14.577Z",
  "pubdate": "2026-08-26T15:17:14.577Z",
  "executiveSummary": "The Linux kernel qeth network driver is susceptible to an integer underflow vulnerability within the SNMP and ARP query ioctl handlers. The vulnerability exists because user-supplied buffer length parameters are processed without adequate lower-bound validation, leading to an integer wrap-around scenario.\nThis flaw can be exploited by an attacker with access to the ioctl interface to cause an out-of-bounds memory write, potentially resulting in kernel heap corruption, system instability, or arbitrary code execution.\nAffected products include the Linux kernel's s390 architecture qeth driver. The risk is considered high due to the potential for kernel-level memory corruption. Exploitation requires the ability to invoke specific ioctls on the s390 platform, which typically necessitates local user access to the device node.\nSuccessful exploitation allows an attacker to bypass length validation checks during kernel memory operations, leading to memory corruption beyond the boundaries of the allocated buffer.",
  "technicalDetails": "The vulnerability stems from improper validation of the udata_len parameter in qeth_snmp_command() and qeth_l3_arp_query() functions within the s390 qeth driver. The driver performs a dynamic memory allocation via kzalloc() based on an unchecked user-supplied length (udata_len). Subsequently, a fixed non-zero value, udata_offset, is defined and passed alongside the length to a reply callback function.\nThe internal bounds checking logic in the callback follows the pattern: if ((udata_len - udata_offset) < len). Both udata_len and udata_offset are defined as u32 types. When an attacker provides a udata_len that is smaller than the fixed udata_offset, the subtraction operation results in an integer underflow, causing the value to wrap around to a very large positive integer. Because the wrapped value is significantly larger than the expected length (len), the conditional check evaluates to false, effectively bypassing the intended security guard.\nOnce the check is bypassed, the subsequent memcpy() operation executes, writing data past the original memory allocation. This creates a classic heap-based out-of-bounds write primitive. Furthermore, if a udata_len of 0 is provided, kzalloc() returns a ZERO_SIZE_PTR. Because the existing NULL check fails to account for this specific pointer value, the code proceeds to perform invalid memory operations using an improperly initialized pointer.\nThe attack flow proceeds as follows: 1) The attacker initiates an ioctl call (SNMP or ARP query) with a crafted udata_len smaller than udata_offset. 2) The kernel allocates insufficient memory for the requested operation. 3) The callback function performs the vulnerable subtraction, triggering an integer underflow that bypasses the sanity check. 4) The kernel executes a memcpy() that writes attacker-controlled data into adjacent kernel heap memory, corrupting critical structures or potentially overwriting function pointers to hijack execution flow. 5) This leads to a kernel panic or escalated privileges depending on the target structures corrupted during the heap overflow."
}