CVE-2026-98205
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A bug in handling input-device commands can let a program on the same computer read leftover pieces of internal operating-system memory.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The EVIOCSABS ioctl handler performs a partial copy_from_user into an on-stack input_absinfo structure whose trailing bytes retain uninitialized kernel stack contents; the structure is then stored to dev->absinfo and later returned by EVIOCGABS, disclosing stale stack bytes to userspace.
Why it matters to the business
Attackers with local access can obtain fragments of kernel memory that may contain credentials, pointers, or other sensitive data, increasing the risk of privilege escalation or further kernel exploitation on affected systems.
How an attack unfolds
An unprivileged local process opens an evdev device node, issues EVIOCSABS with an _IOC_SIZE smaller than sizeof(struct input_absinfo) to leave stack bytes uncleared, then issues EVIOCGABS on the same slot to read the leaked data back into userspace.
How to fix it
Apply the upstream patch that zeros the input_absinfo structure before the copy_from_user call; rebuild and deploy the fixed kernel. Until patched kernels are available, restrict unprivileged access to evdev nodes via device permissions or namespaces.
How to confirm the fix worked
Confirm the fix by inspecting the evdev EVIOCSABS handler for an explicit memset or zero-initialization of the absinfo structure prior to copy_from_user; test by repeating the short-size ioctl sequence and verifying that returned data contains only zeros in the unsupplied fields.
Typical attack path
- Open /dev/input/eventX or equivalent evdev node
- Craft EVIOCSABS ioctl with controlled short size via _IOC_SIZE
- Issue the ioctl to store partially initialized absinfo
- Issue EVIOCGABS to retrieve the structure containing stack bytes
- Parse returned data for useful kernel memory artifacts
How to detect it
Examine audit logs or eBPF traces for repeated EVIOCSABS/EVIOCGABS ioctl sequences with _IOC_SIZE values smaller than sizeof(struct input_absinfo) on evdev file descriptors; correlate with processes that do not normally interact with input devices.
What your security team should do
- Prioritize kernel updates on all systems exposing evdev interfaces to untrusted users
- Harden device permissions so only intended processes can open input event nodes
- Monitor for future kernel releases containing the zero-initialization change
- Consider seccomp filters that block or restrict EVIOCSABS ioctls where feasible
The record
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 input_absinfo: if (copy_from_user(&abs, p, min_t(size_t, size, sizeof(struct input_absinfo)))) The size comes from _IOC_SIZE() 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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|