From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 593F93D6CC4 for ; Wed, 13 May 2026 07:37:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778657871; cv=none; b=BB7TsZ44KT0SYrGkyF7WCkvomC96evawccrgAJQkOIg2lfQs/mx1RH1oV3FJykpkFrM494q/NuTt3SiDmt5tBu+tcMdDmTuQv77VawG3FaF9Nat43FEvxbZ5re9zktgxkeyDcsQ/eL5Jm4dTeUFlOlplqS5cLLZIsz2dFOa9JCk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778657871; c=relaxed/simple; bh=yUkoUjVcsDuhGiBgg22lcONqeZOThJxdgfTDWvID+Qg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=vF0ieawqlCJkUnPAZpfydk/2owz2zLLuUIXNlVT4DNpVh4bQRZeAMtrLpKJI8E91vF0aOs3Xx4A3ztlG8vZmN2IS8FMKz3ZK51nKRE73vdb2jjDiZN0/uBz1/HHUOru7F6AIz6g1ww2pUVmUQsipduL5PffaCuPuoB+6r0/WVqk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=Z1sg4zZ1; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="Z1sg4zZ1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=bt Qp0D6vHdKR6HkgZFmsrQBrm2zmBt70kTdlxMSUbIk=; b=Z1sg4zZ1rocTsjjvSj nd/SHKj6ZsEVtIs+y5PoqcZzffEG6D3QshMFn19k0escRlaHY4FVzCqWkBFRcNa6 z9nsGFAJRibbXZvX9lCmIgs/upiXeVxKyCbxj50hW03SlEI7qn93uxBxChvOWrn2 bI4F9hZSXwckHbEr9R2wpmcD0= Received: from wmy.localdomain (unknown []) by gzga-smtp-mtada-g0-4 (Coremail) with SMTP id _____wCHZeETKgRqTjh7BA--.6891S2; Wed, 13 May 2026 15:37:01 +0800 (CST) From: To: Dave Airlie , Thomas Zimmermann , Jocelyn Falempe Cc: Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Mingyu Wang <25181214217@stu.xidian.edu.cn> Subject: BUG: drm/ast: soft lockup due to missing timeout in hardware polling (ast_2500_patch_ahb) Date: Wed, 13 May 2026 15:36:48 +0800 Message-Id: <20260513073649.352831-1-w15303746062@163.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wCHZeETKgRqTjh7BA--.6891S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KryUuFyrWFy8Ar4fWF17Jrb_yoW5Jr1fpa yY9ws8KayDJ3WDKa48Aa1xZryrZw4rKay5GFykKr1Fvw1DKF9Yyr1Sqwsxt3W7C39FyFyS q3Wqqryj9ayDZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jntxDUUUUU= X-CM-SenderInfo: jzrvjiatxuliiws6il2tof0z/xtbC-x0tEWoEKh2vCAAA3g From: Mingyu Wang <25181214217@stu.xidian.edu.cn> 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: __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 <25181214217@stu.xidian.edu.cn> Best regards, Mingyu Wang