CVE-2026-98201

What it actually does

The compat handler in input_ff_effect_from_user copies only the smaller ff_effect_compat prefix into a caller-provided native ff_effect struct without zeroing the remainder, leaving uninitialized kernel stack bytes that are later stored in ff->effects[] and leaked to userspace via UI_BEGIN_FF_UPLOAD.

Why it matters to the business

Attackers with local access can read fragments of kernel memory, potentially exposing sensitive data such as credentials, encryption keys, or other process information and increasing the risk of further privilege escalation or data theft on affected systems.

How an attack unfolds

A local attacker invokes EVIOCSFF ioctl through the evdev compat path with an uninitialized stack object, triggering the partial copy that retains prior stack contents; the kernel then exposes those bytes when a uinput force-feedback daemon reads the effect back.

How to fix it

Apply the upstream patch that zeros the native ff_effect structure before the compat copy; rebuild and reboot into the fixed kernel. Where immediate patching is not possible, restrict unprivileged access to input and uinput devices via device permissions or seccomp filters.

How to confirm the fix worked

Confirm the patch is present by inspecting the input_ff_effect_from_user function for an explicit zeroing of the effect structure before the compat copy_from_user call; test by exercising the compat EVIOCSFF path and verifying that no prior stack contents appear in the returned effect data.

Typical attack path

1. Obtain local unprivileged access to a system running an affected kernel
2. Open an input device and issue EVIOCSFF ioctl using the compat interface
3. Trigger storage of the partially-initialized ff_effect structure
4. Use UI_BEGIN_FF_UPLOAD to read the effect and extract leaked kernel stack bytes

How to detect it

Monitor for repeated or anomalous EVIOCSFF ioctls from unprivileged processes and for subsequent UI_BEGIN_FF_UPLOAD reads that return effect structures containing non-zero padding or recognizable kernel addresses; review audit logs for input subsystem activity and inspect uinput-using daemons for unexpected memory reads.

What your security team should do

• Prioritize kernel updates on multi-user or internet-facing Linux systems within the next maintenance window
• Audit systems for custom or third-party input/uinput drivers that may bypass the fix
• Reduce attack surface by disabling unnecessary input device access for non-root users