Hi Am 13.05.26 um 09:36 schrieb [email protected]:
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.
Thanks for reporting. Will you send a patch? Best regards Thomas
Reported-by: Mingyu Wang <[email protected]> Best regards, Mingyu Wang
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
