From: Mingyu Wang <[email protected]>
Hi all,
While analyzing the AST driver's hardware interactions using our custom device
emulation and fuzzing framework (DevGen), we observed a severe soft lockup in
the DRM driver.
Although the underlying trigger in our environment was an incomplete emulation
of the ASPEED AHB bridge, this highlighted a critical defensive programming gap
in the driver itself: a complete lack of timeout mechanisms in the hardware
polling loops.
This issue causes a complete system hang (CPU stuck for 143s+) and leads to
subsequent I/O starvation and system paralysis (e.g., jbd2 and systemd-journald
blocked).
### Crash Log Snippet
watchdog: BUG: soft lockup - CPU#3 stuck for 143s! [systemd-udevd:162]
RIP: 0010:ioread32+0x0/0xa0
Call Trace:
<TASK>
__ast_read32
__ast_mindwm+0x4d/0x80 [ast]
ast_2500_patch_ahb+0x9d/0x120 [ast]
ast_detect_chip
ast_pci_probe+0xa1a/0xb70 [ast]
...
### Vulnerability Analysis
Even on bare-metal hardware, an unresponsive ASPEED chip, a PCIe bus fault, or
unexpected hardware states can cause the kernel to hang forever in the
following loops during initialization:
1. Inside `ast_2500_patch_ahb()`:
do {
__ast_moutdwm(regs, 0x1e6e2000, 0x1688A8A8);
data = __ast_mindwm(regs, 0x1e6e2000);
} while (data != 1); // <--- Infinite loop if hardware doesn't respond
properly
2. Inside the underlying I/O accessors `__ast_mindwm()` and `__ast_moutdwm()`:
do {
data = __ast_read32(regs, 0xf004) & 0xffff0000;
} while (data != (r & 0xffff0000)); // <--- Infinite loop
### Proposed Fix Direction
To prevent the kernel from hanging indefinitely and to gracefully abort the
probe (`-ENODEV`) upon hardware failure, these loops must implement a timeout
mechanism (e.g., using `readx_poll_timeout` or a loop counter with `udelay`).
Interestingly, other functions in the same file (e.g., `mmc_test`) correctly
implement a timeout counter (`if (++timeout > TIMEOUT) return false;`), but the
initialization paths mentioned above blindly trust the hardware state.
We are reporting this defect so that the maintainers can decide the appropriate
timeout thresholds and implement a safe fallback mechanism across the `ast`
driver.
Please let us know if you need more information or the full dmesg log.
Reported-by: Mingyu Wang <[email protected]>
Best regards,
Mingyu Wang
