| Message ID | 397628f5644f6488f111a3a3ee07d00ce01a13b0.1783977550.git.sean@mess.org (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-24411-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114]) by mxe881.netcup.net (Postfix) with ESMTPS id 6ACF11C00A4 for <noreply@patchwork.local>; Mon, 13 Jul 2026 23:31:51 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=mess.org; dkim=pass header.d=mess.org; spf=pass (sender IP is 172.105.105.114) smtp.mailfrom=linux-sunxi+bounces-24411-noreply=patchwork.local@lists.linux.dev smtp.helo=tor.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.105.105.114 as permitted sender) client-ip=172.105.105.114; envelope-from=linux-sunxi+bounces-24411-noreply=patchwork.local@lists.linux.dev; helo=tor.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id D518C3034191 for <noreply@patchwork.local>; Mon, 13 Jul 2026 21:31:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9DEB3363C53; Mon, 13 Jul 2026 21:31:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mess.org header.i=@mess.org header.b="tk+Uuiz7"; dkim=pass (2048-bit key) header.d=mess.org header.i=@mess.org header.b="tk+Uuiz7" X-Original-To: linux-sunxi@lists.linux.dev Received: from extorris.mess.org (extorris.mess.org [92.243.27.206]) (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 C51373624DB for <linux-sunxi@lists.linux.dev>; Mon, 13 Jul 2026 21:31:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=92.243.27.206 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783978295; cv=none; b=AMAHMm+tA1bucB61jWM+tEE35Sok3W3XZRUgXxHwxW1YuXlZyTprIWRJBvOdDLoOrvlGmW/vVe59u9EOVlbr8jKfMlW0xAK9dcqD2Y8xmQXN8eLo+0SbWYG3QJc8iHGzHCa1jtIUhqPmTJ0gV9sFihz305QX/kt65MYCz+qpNZU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783978295; c=relaxed/simple; bh=PFYYQhVg4NRarAQ81g5gFeRQ3Pkd+XUXZYeUxj9P9Kk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R5DpzjUCXdp2eWZstGmWPSnGHFeiob3X9hy5lvk39jJOfRHPq6YOnUWzc818I5WKrwbEAhtLVRfb/Uhpj0tqzqG0f5QCx4CNBANRZGR6hxOmHob4jw7OF5gDoK3h9aFalWsEpd/rye9thRya379hSLLTUhIRJdAQgSsnnrAG8Lc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mess.org; spf=pass smtp.mailfrom=mess.org; dkim=pass (2048-bit key) header.d=mess.org header.i=@mess.org header.b=tk+Uuiz7; dkim=pass (2048-bit key) header.d=mess.org header.i=@mess.org header.b=tk+Uuiz7; arc=none smtp.client-ip=92.243.27.206 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mess.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mess.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mess.org; s=2020; t=1783978284; bh=PFYYQhVg4NRarAQ81g5gFeRQ3Pkd+XUXZYeUxj9P9Kk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tk+Uuiz7dx6b0K76rO+IqBr7UYSiJuIM3z/Nm1TLA1YJECFKTxPulnLmu6f3PWM98 d38LYkaWefQXGkU15JYrHREz1+XE2OJYiqVzitLuI8qMJfvjxVsjK2+pPYAdbUTEFv oPSeMjTTtMUUs+xCkBRuQyAHP3d2gkuB/7/FWJPWxVmwyXX7qQf/XuZZjH7KW12ekS DXPghBtGhMJEPhtdp1xfU4nSaitT5urfWLpvwrLFB0F5ooN+aELeVveuJT29CdlLcn YOHuMYcSP/7L7ox8/ZAe4FVPJDpqae82Lgc+LzekMTunD0O33RAdYuBxGmep8cw3Jg W7VfVBwzgYrpA== Received: by extorris.mess.org (Postfix, from userid 1004) id E7AF141E9D; Mon, 13 Jul 2026 22:31:24 +0100 (BST) X-Spam-Level: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mess.org; s=2020; t=1783978284; bh=PFYYQhVg4NRarAQ81g5gFeRQ3Pkd+XUXZYeUxj9P9Kk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tk+Uuiz7dx6b0K76rO+IqBr7UYSiJuIM3z/Nm1TLA1YJECFKTxPulnLmu6f3PWM98 d38LYkaWefQXGkU15JYrHREz1+XE2OJYiqVzitLuI8qMJfvjxVsjK2+pPYAdbUTEFv oPSeMjTTtMUUs+xCkBRuQyAHP3d2gkuB/7/FWJPWxVmwyXX7qQf/XuZZjH7KW12ekS DXPghBtGhMJEPhtdp1xfU4nSaitT5urfWLpvwrLFB0F5ooN+aELeVveuJT29CdlLcn YOHuMYcSP/7L7ox8/ZAe4FVPJDpqae82Lgc+LzekMTunD0O33RAdYuBxGmep8cw3Jg W7VfVBwzgYrpA== Received: from maru.home (host86-148-148-68.range86-148.btcentralplus.com [86.148.148.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by extorris.mess.org (Postfix) with ESMTPSA id D531040155; Mon, 13 Jul 2026 22:31:23 +0100 (BST) From: Sean Young <sean@mess.org> To: linux-media@vger.kernel.org, Sean Young <sean@mess.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Chen-Yu Tsai <wens@kernel.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, Patrice Chotard <patrice.chotard@foss.st.com>, Hans Verkuil <hverkuil+cisco@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 06/11] media: sunxi-cir: Ensure no more interrupts can occur before free Date: Mon, 13 Jul 2026 22:31:00 +0100 Message-ID: <397628f5644f6488f111a3a3ee07d00ce01a13b0.1783977550.git.sean@mess.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <cover.1783977550.git.sean@mess.org> References: <cover.1783977550.git.sean@mess.org> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
None
|
|
Commit Message
Sean Young
July 13, 2026, 9:31 p.m. UTC
Only call rc_free_device() once the hardware has been stopped.
Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks")
Signed-off-by: Sean Young <sean@mess.org>
---
drivers/media/rc/sunxi-cir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: Pre-existing issues: - [High] The teardown sequence fails to synchronize with or disable the active devm-managed IRQ handler, leaving a race window that guarantees either a fatal bus error (unclocked register access) or a Use-After-Free. - [High] Device interfaces and the IRQ handler are registered before hardware initialization in probe(), allowing userspace or interrupts to access unclocked registers and cause a bus fault. - [High] The suspend callback disables clocks without synchronizing or disabling the device interrupt, allowing an unclocked MMIO access race. -- --- Patch [6]: [PATCH v2 06/11] media: sunxi-cir: Ensure no more interrupts can occur before free --- commit 2912f57e54d0f869a5daead9e5ddf88c0db3d980 Author: Sean Young <sean@mess.org> media: sunxi-cir: Ensure no more interrupts can occur before free This commit attempts to fix a race condition during module removal by moving the call to rc_free_device() after sunxi_ir_hw_exit(). > diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c > --- a/drivers/media/rc/sunxi-cir.c > +++ b/drivers/media/rc/sunxi-cir.c > @@ -374,8 +374,8 @@ static void sunxi_ir_remove(struct platform_device *pdev) > struct sunxi_ir *ir = platform_get_drvdata(pdev); > > rc_unregister_device(ir->rc); > - rc_free_device(ir->rc); > sunxi_ir_hw_exit(&pdev->dev); > + rc_free_device(ir->rc); [Severity: High] This isn't a bug introduced by this patch, but does the teardown sequence leave a race window with the devm-managed IRQ handler? The commit message mentions ensuring no more interrupts can occur before free, but sunxi_ir_hw_exit() only disables the clocks and asserts reset: sunxi_ir_hw_exit() { clk_disable_unprepare(ir->clk); clk_disable_unprepare(ir->apb_clk); reset_control_assert(ir->rst); } Because the IRQ is managed by devm_request_irq(), it remains active until after sunxi_ir_remove() returns. If an interrupt fires concurrently after the clocks are disabled, sunxi_ir_irq() will attempt to access unclocked MMIO registers: sunxi_ir_irq() { ... status = readl(ir->base + SUNXI_IR_RXSTA_REG); Could this lead to a synchronous external abort? Should there be an explicit disable_irq() or similar synchronization before disabling the clocks? Additionally, this same pattern appears to exist in sunxi_ir_suspend(), which also calls sunxi_ir_hw_exit() while the IRQ is still globally active. [Severity: High] This is also a pre-existing issue, but is there a similar unclocked access risk during driver initialization? In sunxi_ir_probe(), rc_register_device() and devm_request_irq() are called before the hardware clocks are enabled via sunxi_ir_hw_init(): sunxi_ir_probe() { ... ret = rc_register_device(ir->rc); ... ret = devm_request_irq(dev, ir->irq, sunxi_ir_irq, 0, SUNXI_IR_DEV, ir); ... ret = sunxi_ir_hw_init(dev); } If userspace immediately issues a LIRC_SET_REC_TIMEOUT ioctl after the device is registered, sunxi_ir_set_timeout() will write to SUNXI_IR_CIR_REG before the clocks are enabled. Similarly, a pending interrupt could cause sunxi_ir_irq() to run before sunxi_ir_hw_init(). Should the hardware initialization be moved before exposing the device and requesting the IRQ? > }
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c index 28e840a7e5b8..af1ee08ffdbe 100644 --- a/drivers/media/rc/sunxi-cir.c +++ b/drivers/media/rc/sunxi-cir.c @@ -374,8 +374,8 @@ static void sunxi_ir_remove(struct platform_device *pdev) struct sunxi_ir *ir = platform_get_drvdata(pdev); rc_unregister_device(ir->rc); - rc_free_device(ir->rc); sunxi_ir_hw_exit(&pdev->dev); + rc_free_device(ir->rc); } static void sunxi_ir_shutdown(struct platform_device *pdev)