CVE-2026-64483 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire: isight: bound the sample count to the packet payload
isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length.
count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count);
length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer.
payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range.
A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture.
Add the MAX_FRAMES_PER_PACKET bound to the gate.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability resides within the Linux kernel's ALSA subsystem specifically in the firewire isight driver implementation, representing a critical buffer overflow condition that could lead to arbitrary code execution or system compromise. This flaw manifests when processing audio data from Apple iSight cameras connected via FireWire bus, where the device sends malformed packet data that bypasses normal validation checks. The issue stems from insufficient bounds checking in the isight_packet() function which processes incoming ISO packets without properly validating sample count parameters against buffer boundaries.
The technical implementation flaw occurs at the intersection of data validation and memory management within the audio capture pipeline. The original code extracts a sample count value from the packet payload using be32_to_cpu() function and performs only a preliminary check against the packet header length, specifically calculating an upper bound as (length - 16) / 4 where length represents the ISO header data_length field that can reach maximum values of 0xffff. This calculation creates a dangerous window where sample counts could theoretically exceed 16379 frames, far exceeding the actual buffer capacity. The vulnerability is classified under CWE-129 as an insufficient validation of array index or buffer bounds, while also mapping to ATT&CK technique T1059.008 for execution through valid system components.
The operational impact extends beyond simple memory corruption to potentially enable privilege escalation and system instability when a malicious or faulty iSight device attempts to exploit this condition during normal capture operations. The payload->samples field contains only 2 * MAX_FRAMES_PER_PACKET values, meaning each frame actually requires two samples due to device multiplexing, yet the original code allows sample counts to exceed this limit by reading past the payload buffer boundary. Additionally, when count values surpass the buffer size limits, writes extend beyond the runtime->dma_area memory region, creating potential for data corruption or code execution. The vulnerability is particularly dangerous because it requires no special privileges beyond normal device access and can be triggered through legitimate capture operations.
The mitigation strategy involves implementing proper bounds checking by adding MAX_FRAMES_PER_PACKET as a hard limit to the validation gate, effectively preventing both read and write operations from exceeding buffer boundaries. This fix ensures that sample count values are constrained to valid ranges regardless of input data from potentially malicious devices on the FireWire bus. The solution aligns with security best practices for defensive programming and buffer overflow prevention, specifically addressing the root cause rather than merely patching symptoms. The fix demonstrates proper input validation techniques that should be applied across similar kernel subsystems handling external device communications, particularly in real-time audio processing components where timing and data integrity are critical for system stability and security.