CVE-2026-80575 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: cs40l50-vibra - validate custom data from user space
cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything:
work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len;
The driver then reads two words out of that buffer: custom_data[0] as the
waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the
index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled:
- custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it.
- custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one
word past the allocation.
The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes
the "bank_type >= CS40L50_WVFRM_BANK_NUM" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the
switch statement's default case gets a chance to reject it:
base_index = vib->dsp.banks[effect->type].base_index;
max_index = vib->dsp.banks[effect->type].max_index;
Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability identified in the cs40l50-vibra audio subsystem represents a critical failure in input validation and memory safety, specifically within the handling of force feedback effects submitted by user space applications via the EVIOCSFF ioctl interface. The core technical flaw lies in how the driver processes custom data associated with FF_PERIODIC or FF_CUSTOM effect types. When such an effect is registered, the kernel function cs40l50_add() invokes memdup_array_user to copy a buffer of s16 values from user space into kernel memory based on a length parameter provided by the untrusted user input. This operation lacks sufficient boundary checks before subsequent logic accesses specific indices within this newly allocated buffer, creating conditions for both out-of-bounds reads and logical errors in type handling that can lead to system instability or potential privilege escalation vectors depending on the exploitation context.
The first major aspect of this vulnerability involves improper length validation leading to invalid memory dereferences. The driver retrieves two 16-bit words from the custom_data buffer: the first word is interpreted as a waveform bank identifier, and the second as an index within that bank. However, there are no checks ensuring that at least these two words exist in the user-supplied data. If the user specifies a length of zero for the custom data, memdup_array_user returns ZERO_SIZE_PTR rather than NULL or an error code, which is standard behavior for allocating zero bytes but dangerous when subsequently dereferenced. Consequently, accessing custom_data[0] results in a null pointer dereference or access to invalid memory addresses, potentially causing a kernel panic or denial of service. Similarly, if the user specifies a length of one byte (or insufficient words), the allocation is too small to hold two s16 values. Accessing custom_data[1] then constitutes an out-of-bounds read beyond the allocated buffer boundary, which can leak sensitive kernel memory contents into the driver's internal state or cause undefined behavior depending on what resides in adjacent memory regions.
Beyond immediate memory safety issues, there is a significant logical vulnerability related to type handling and array indexing bounds checking. The waveform bank value extracted from custom_data[0] is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in a signed 16-bit integer variable of type s16. This design choice introduces a sign-extension issue where values greater than or equal to 0x8000 are interpreted as negative numbers due to two's complement representation. The subsequent validation check compares this bank value against CS40L50_WVFRM_BANK_NUM, which is typically a small positive integer representing the number of valid waveform banks. Because negative values pass this greater-than-or-equal-to comparison incorrectly (as they are less than any positive upper bound), the driver proceeds to use this invalid negative index to access vib->dsp.banks[]. This results in an out-of-bounds array read, accessing memory locations preceding the start of the banks array structure. Such accesses can corrupt internal kernel data structures or expose sensitive information contained within adjacent fields of the vibration device object.
The operational impact of these vulnerabilities is severe, primarily manifesting as a local denial of service through kernel crashes when triggered by unprivileged user space processes attempting to set up force feedback effects on compatible haptic hardware. In more sophisticated exploitation scenarios, particularly where out-of-bounds reads leak kernel memory contents or if the vulnerability can be chained with other primitives for arbitrary read/write capabilities, it could potentially lead to privilege escalation. The lack of proper validation allows attackers to probe kernel memory layouts and internal state structures, undermining system integrity and confidentiality guarantees provided by standard isolation mechanisms. This aligns closely with CWE-125 (Out-of-bounds Read) and CWE-787 (Out-of-bounds Write if write paths exist in related logic), as well as ATT&CK technique T1046 (Network Service Scanning) or more accurately T1003 (OS Credential Dumping) if memory leaks are utilized for credential extraction, though primarily it falls under local exploitation techniques involving improper input validation.
To mitigate these risks, the driver implementation must enforce strict length checks before attempting to access specific indices within user-supplied buffers. Specifically, any request for custom data with a length insufficient to contain at least two s16 values (i.e., less than four bytes) should be rejected immediately with an error code such as -EINVAL or -EFAULT. Furthermore, the waveform bank value extracted from the buffer must be stored in an unsigned integer type, such as u32, after applying any necessary masks, ensuring that all bit patterns are treated as positive values during bounds checking. This ensures that the upper-bound comparison against CS40L50_WVFRM_BANK_NUM correctly rejects invalid indices regardless of their original binary representation. Adopting these changes aligns with best practices observed in other similar drivers like da7280, which already implement robust range checks for custom length parameters, thereby preventing both memory safety violations and logical bypasses of security controls within the kernel subsystem.