CVE-2026-74673: Input: evdev - fix information leak in evdev_pass_values()
In the Linux kernel, the following vulnerability has been resolved:
Input: evdev - fix information leak in evdevpassvalues()
In evdevpassvalues(), the inputevent structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct inputevent contains explicit or implicit padding (such as the 32-bit pad field on SPARC64), these padding bytes are left uninitialized.
When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information.
Similar issues exist in evdevqueuesyndropped and passevent.
Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1 - Configuration
In evdev_pass_values(), explicitly clear the entire allocated input_event structure using memset() before it is populated field-by-field and passed to the client buffer, so no uninitialized padding bytes leak to userspace.
Linux kernel (Input: evdev) memset initialization of struct input_event padding/uninitialized bytes in evdev_pass_values() = memset(input_event, 0, sizeof(*input_event)) - Configuration
In __evdev_queue_syn_dropped and __pass_event, explicitly zero the entire relevant event structure (including explicit/implicit padding) with memset() before copying to client/userspace, to prevent information leakage from uninitialized padding.
Linux kernel (Input: evdev) memset initialization for event structures in __evdev_queue_syn_dropped and __pass_event = memset(..., 0, sizeof(...))
Event History
Frequently Asked Questions
Who could receive the leaked kernel memory?
Clients that receive evdev input events in userspace could receive event structures containing uninitialized padding bytes. The leak occurs when those structures are copied across the kernel-to-userspace boundary.
What must be true for exploitation to occur?
An attacker needs access to an evdev client path that receives input events from the affected kernel. The issue is an information disclosure caused by uninitialized stack padding in events delivered to userspace.
Are all affected code paths limited to normal input event delivery?
No. The description identifies similar uninitialized-padding issues in __evdev_queue_syn_dropped and __pass_event in addition to evdev_pass_values().
How is the issue fixed?
The event structure is explicitly zeroed with memset() before its fields are populated, clearing explicit or implicit padding before the structure can be copied to userspace.