CVE-2020-36787 in Linux
Summary
by MITRE • 02/28/2024
In the Linux kernel, the following vulnerability has been resolved:
media: aspeed: fix clock handling logic
Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below.
Enable eclk De-assert Video Engine reset 10ms delay Enable vclk
It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot.
To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails.
clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 12/11/2024
The vulnerability described in CVE-2020-36787 represents a critical clock handling flaw within the Linux kernel's Aspeed video engine driver, specifically affecting AST2500 System-on-Chip implementations. This issue stems from improper synchronization between clock enabling sequences and hardware reset assertions, creating a race condition that can lead to unpredictable memory corruption patterns. The video engine utilizes two primary clock sources: eclk and vclk, where the reset control is intrinsically coupled with eclk. The problematic sequence previously involved enabling eclk first, then de-asserting the video engine reset, followed by a 10ms delay before enabling vclk. This ordering creates a window where hardware state becomes inconsistent, potentially triggering unexpected DMA memory transfers that corrupt memory regions in random and sporadic patterns. The vulnerability's rarity and intermittent nature makes it particularly challenging to debug and reproduce, as evidenced by the critical kernel panics that occur with various signature patterns.
The technical flaw manifests in the clock management logic where the reset de-assertion timing is improperly sequenced relative to clock enabling operations. According to industry standards such as CWE-691, this represents an inadequate control flow management issue where the interaction between hardware reset signals and clock enable operations creates a dangerous state. The vulnerability impacts the Aspeed video engine driver through improper reset control implementation, where reset bit 6 is designated as the 'Video Engine' reset in the datasheet but was not properly synchronized with the eclk clock enable sequence. This misalignment affects all Aspeed SoCs that share the same video engine driver, creating a widespread impact across multiple device models. The improper reset handling creates a condition where hardware state transitions occur in an unpredictable sequence, leading to memory corruption that can manifest as kernel panics during boot processes or system operation.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially destabilize entire system operations, particularly during boot sequences where udevd performs hardware queries that inadvertently activate the video engine hardware for brief periods. This behavior means that even systems not actively utilizing video capabilities can experience the vulnerability, making it particularly insidious. The issue's occurrence during system boot processes, when udevd turns on the video engine hardware for queries, creates a persistent threat vector that can cause system instability. From an ATT&CK framework perspective, this vulnerability maps to techniques involving privilege escalation and system resource manipulation, as the memory corruption can potentially be leveraged to gain unauthorized access or cause system denial of service. The sporadic nature of the issue means that detection and remediation are extremely challenging, as the problem may not manifest consistently under normal operating conditions.
The fix implemented in this patch addresses the core issue by modifying the clock handling logic to ensure reset de-assertion occurs after both eclk and vclk clocks are enabled, eliminating the race condition that previously allowed for hardware state inconsistencies. This change aligns with the reset settings for eclk and vclk to match previous Aspeed SoC implementations defined in clk-aspeed.c, ensuring consistency across the entire Aspeed SoC family. The solution also incorporates proper cleanup procedures by adding clk_unprepare calls in probe failure scenarios, preventing potential resource leaks or inconsistent hardware states. The fix specifically addresses the reset bit 6 designation as the 'Video Engine' reset, ensuring that this reset signal is properly de-asserted when eclk is enabled, thereby synchronizing hardware initialization with clock management. This resolution not only fixes the immediate memory corruption issue but also establishes a more robust foundation for hardware initialization sequences that can prevent similar vulnerabilities from emerging in related components. The patch demonstrates proper adherence to kernel development practices by ensuring that hardware reset sequences are properly synchronized with clock enable operations, reducing the attack surface and improving overall system stability.