CVE-2020-36787

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: aspeed: fix clock handling logic<br /> <br /> Video engine uses eclk and vclk for its clock sources and its reset<br /> control is coupled with eclk so the current clock enabling sequence works<br /> like below.<br /> <br /> Enable eclk<br /> De-assert Video Engine reset<br /> 10ms delay<br /> Enable vclk<br /> <br /> It introduces improper reset on the Video Engine hardware and eventually<br /> the hardware generates unexpected DMA memory transfers that can corrupt<br /> memory region in random and sporadic patterns. This issue is observed<br /> very rarely on some specific AST2500 SoCs but it causes a critical<br /> kernel panic with making a various shape of signature so it&amp;#39;s extremely<br /> hard to debug. Moreover, the issue is observed even when the video<br /> engine is not actively used because udevd turns on the video engine<br /> hardware for a short time to make a query in every boot.<br /> <br /> To fix this issue, this commit changes the clock handling logic to make<br /> the reset de-assertion triggered after enabling both eclk and vclk. Also,<br /> it adds clk_unprepare call for a case when probe fails.<br /> <br /> clk: ast2600: fix reset settings for eclk and vclk<br /> Video engine reset setting should be coupled with eclk to match it<br /> with the setting for previous Aspeed SoCs which is defined in<br /> clk-aspeed.c since all Aspeed SoCs are sharing a single video engine<br /> driver. Also, reset bit 6 is defined as &amp;#39;Video Engine&amp;#39; reset in<br /> datasheet so it should be de-asserted when eclk is enabled. This<br /> commit fixes the setting.