Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:13.530Z",
  "pubdate": "2026-08-26T15:17:13.530Z",
  "executiveSummary": "The Linux kernel driver for the cs40l50 haptic actuator is vulnerable to out-of-bounds (OOB) memory access due to insufficient validation of user-provided input within the FF_PERIODIC/FF_CUSTOM effect implementation.\nThe vulnerability originates from the driver's failure to verify the length and content of custom effect data passed via the EVIOCSFF ioctl. An attacker with local access to the system can provide malicious input that triggers out-of-bounds reads or memory corruption.\nSuccessful exploitation allows an unprivileged user to perform OOB reads or potentially cause a kernel panic, leading to local denial-of-service conditions. Depending on the memory layout and heap state, this could theoretically be leveraged for information disclosure or further privilege escalation.\nThe issue affects systems utilizing the cs40l50 driver for haptic feedback. Remediation requires implementing strict bounds checking on the 'custom_len' field and ensuring that all array indices are properly sanitized before use.",
  "technicalDetails": "The vulnerability exists within the 'cs40l50_add()' function of the cs40l50-vibra driver. When processing custom haptic effects, the driver uses 'memdup_array_user()' to allocate and copy data from user-space provided by the 'ff_effect' structure into a kernel buffer.\nRoot Cause: The driver fails to validate 'periodic->custom_len' before proceeding to access 'custom_data' at indices [0] and [1]. If 'custom_len' is 0, 'memdup_user()' returns 'ZERO_SIZE_PTR' rather than an error, causing the subsequent dereference of 'custom_data[0]' to trigger an invalid memory access. If 'custom_len' is 1, only two bytes are allocated, leading to an OOB read when the driver attempts to access 'custom_data[1]'.\nLogic Error in Indexing: The driver extracts 'custom_data[0]' to identify the waveform bank and 'custom_data[1]' to identify the index within that bank. The bank value is masked using 'CS40L50_CUSTOM_DATA_MASK' (0xffff) but stored in a signed 16-bit integer ('s16'). Values of 0x8000 or greater result in negative values due to sign extension. This bypasses the subsequent 'bank_type >= CS40L50_WVFRM_BANK_NUM' boundary check.\nAttack Flow: An attacker initiates an 'EVIOCSFF' ioctl call with a crafted 'ff_effect' payload. By setting 'custom_len' to 0 or 1, the attacker forces the kernel to read from unallocated memory or past the end of the allocated heap buffer. Alternatively, by setting 'custom_data[0]' to a value that interprets as a negative index, the attacker forces the kernel to access 'vib->dsp.banks[]' with an out-of-bounds offset before the code reaches the switch statement that would normally catch invalid indices.\nPost-Exploitation: The primary impact is an OOB memory access which typically leads to an 'Oops' or kernel panic. Because this happens in the context of haptic effect processing, it remains a local attack vector. If the OOB read occurs near sensitive heap structures, an attacker may use this to leak kernel pointers or internal driver state, facilitating further exploitation."
}