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.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects Aspeed video engine clock and reset handling. On some AST2500 systems, incorrect sequencing can cause unexpected DMA memory transfers, corrupting memory and causing rare but critical kernel panics, even when the video engine is only briefly queried during boot.
Executive priority
Treat this as targeted operational reliability risk for affected Linux-on-Aspeed deployments. It is not supported as actively exploited, but rare kernel panics on infrastructure hardware can still justify timely patch validation where matching hardware exists.
Technical view
The Aspeed media video engine uses eclk and vclk. The vulnerable sequence de-asserts reset after eclk but before vclk, which can improperly reset hardware and trigger sporadic DMA memory corruption. Stable fixes change reset de-assertion to occur after both clocks are enabled and adjust related AST2600 reset settings.
Likely exposure
Exposure appears limited to Linux systems using affected kernel versions with Aspeed video engine hardware, especially specific AST2500 SoCs. The source notes the condition can occur during boot because udevd briefly turns on the video engine for queries.
Exploitation context
No active exploitation is indicated. The CVE is not listed as KEV in the provided bundle. The described impact is unreliable hardware-triggered memory corruption and kernel panic, not a documented remote or local attack path.
Researcher notes
Evidence is strongest for a kernel hardware-initialization flaw rather than a conventional exploit primitive. Public data lacks CVSS, CWE, exploitability analysis, and distribution-specific fixed versions, so validation should focus on hardware presence and kernel backport status.
Mitigation direction
Upgrade to Linux stable releases containing the referenced Aspeed media and clock fixes.
Prioritize systems with Aspeed AST2500 or AST2600 SoCs and video engine support.
Check Linux distribution or vendor advisories for backported fixes.
Monitor affected systems for sporadic boot-time kernel panics or memory corruption symptoms.
Validation and detection
Inventory Linux kernel versions against the affected and fixed ranges in vendor guidance.
Identify systems using Aspeed AST2500 or AST2600 video engine hardware.
Confirm kernel packages include the referenced stable commit fixes.
Review boot logs for video engine probing, panics, or unexplained memory corruption.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2020-36787 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.