CVE-2026-98205: Input: evdev - zero absinfo before partial copy in EVIOCSABS
In the Linux kernel, the following vulnerability has been resolved:
Input: evdev - zero absinfo before partial copy in EVIOCSABS
The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct inputabsinfo:
if (copyfromuser(&abs, p, mint(sizet, size, sizeof(struct inputabsinfo))))
The size comes from IOCSIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device:
dev->absinfo[t] = abs;
EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size.
Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel evdev EVIOCSABS handler, zero the struct input_absinfo before copying the user-supplied data so any portion not supplied by userspace is returned as zero.
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
An attacker needs userspace access sufficient to issue EVIOCSABS and EVIOCGABS ioctl calls against an evdev input device. Exploitation relies on supplying an ioctl command with a deliberately short, userspace-controlled size.
What information can be exposed?
A short EVIOCSABS copy can leave portions of an on-stack input_absinfo structure uninitialized. When the structure is later returned through EVIOCGABS, those stale kernel stack bytes may be disclosed to userspace.
Are normal ioctl sizes affected?
The issue is triggered by an arbitrarily short ioctl size, because the handler copies only the user-specified number of bytes but stores the entire structure. The data provided does not identify a default configuration or normal caller behavior as affected.
What does the fix change?
The fix zero-initializes the input_absinfo structure before copying user data, so fields not supplied by a short ioctl read back as zero. It retains the existing resolution-field fixup for copies that partially overlap that field.