CVE-2021-47282 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
spi: bcm2835: Fix out-of-bounds access with more than 4 slaves
Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.
The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device().
However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[].
As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability identified as CVE-2021-47282 affects the Linux kernel's spi bcm2835 driver implementation, specifically targeting out-of-bounds memory access conditions that occur when configuring more than four SPI slave devices. This issue stems from a fundamental mismatch between compile-time array sizing and runtime device tree configuration handling within the driver's private data structure. The root cause lies in the driver's use of a statically-sized array named prepare_cs[] that was originally constrained to three elements, reflecting the hardware's native chipselect capabilities. The original commit 571e31fa60b3 attempted to address this limitation by enforcing a runtime constraint through setting the controller's num_chipselect parameter to three, effectively rejecting slave configurations with higher chipselect values during device addition. However, this approach failed to account for the device tree's capability to specify GPIO-based chipselects that operate independently of the hardware's native chipselect count, creating a scenario where the system could silently increase the num_chipselect value beyond the statically allocated array boundaries.
The technical flaw manifests as a direct memory access violation when GPIO chipselects are configured for more than three slaves, resulting in buffer overflows within the prepare_cs[] array. This condition occurs because the driver's runtime validation only considers native chipselects while ignoring the device tree's GPIO chipselect specifications that can extend the total slave count beyond the original three-element array limit. The vulnerability represents a classic example of insufficient input validation and boundary checking, where the driver assumes a fixed relationship between hardware capabilities and software configuration parameters without properly accounting for the flexibility provided by device tree overlays. This flaw creates a potential attack surface where malicious or malformed device tree configurations could trigger memory corruption, leading to system instability, privilege escalation, or denial of service conditions. The issue aligns with CWE-129: "Improper Validation of Array Index" and CWE-787: "Out-of-bounds Write" while potentially enabling techniques described in ATT&CK tactic T1059 for privilege escalation through kernel memory corruption.
The operational impact of this vulnerability extends beyond simple system instability to encompass potential security implications for embedded systems and single-board computers running Linux kernels with the affected bcm2835 SPI driver. Systems utilizing Raspberry Pi or similar devices with complex SPI configurations involving more than three slaves could experience system crashes, data corruption, or unauthorized access to kernel memory spaces. The vulnerability particularly affects IoT deployments, industrial control systems, and embedded applications where device tree configurations are commonly used to define complex hardware setups with multiple SPI slaves. The fix implemented addresses this by increasing the allowed slave count to twenty-four elements, which provides sufficient headroom for most practical configurations while maintaining the original three-native-chipselect constraint. This mitigation strategy ensures that the num_chipselect parameter remains properly constrained to the hardware's actual capabilities while moving the validation logic to the slave setup phase where it can properly handle GPIO chipselect configurations. The approach also demonstrates the importance of considering the full device tree specification when implementing hardware driver constraints, as opposed to relying solely on hardware-native capabilities.
The resolution strategy implemented for CVE-2021-47282 represents a pragmatic approach to maintaining backward compatibility while addressing the core architectural issue. By raising the array size to twenty-four elements and moving validation from the device addition phase to the slave setup phase, the fix preserves the original hardware limitation while allowing for more flexible device tree configurations. This approach ensures that the system can properly handle GPIO chipselects without causing memory corruption, though it acknowledges that the long-term solution requires more sophisticated handling of arbitrary slave counts. The fix maintains the three-native-chipselect constraint as the authoritative limit while allowing for the extended configuration through GPIO-based chipselects, effectively creating a hybrid approach that balances hardware limitations with software flexibility. This type of mitigation strategy is commonly recommended in security practices for maintaining system stability while addressing known vulnerabilities, particularly in embedded and IoT environments where hardware and software constraints must be carefully managed to prevent both security issues and system instability. The solution also highlights the importance of thorough testing of device tree configurations and the need for comprehensive validation of hardware abstraction layers in kernel drivers.