From nobody Sun Feb 8 00:03:39 2026 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 381F32D23B6 for ; Tue, 3 Feb 2026 03:20:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770088812; cv=none; b=kxR6GvpMFWAztUovO62YFexxesAYGPtLLqGcnREEaRg4IlL7R1T9p/a+VTBhXF57TMa+Brx34SsvDMjDHPmt43kKStMw1x8wZc/JtbIZ4iAijlUwm01JEmMk8d9Si2R6w00e0hzw9gIu8q4EvALAvCaXFrV84uCfW1vmJG/MnG4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770088812; c=relaxed/simple; bh=oF9G0ApWjWS9adJt1oJ2Ri1rcg62Byrj2l2qL9jSFzI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XAANZQE4mbCTmXVzaO6kTw+Rsd65c4g6+NyPehTvh3nTGOcKj+vjnnviDtLs2k5aEYy8wQjyhaxlCXW6XwqDrGik4OQp9YzkMdSdOWDUj1xLQnA7r804uc47zQyvNn+DVEDL7lm+OwRVsHQgHOQJODM1n2+WA5FFzkepMTxoXio= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Q8OORg/u; arc=none smtp.client-ip=209.85.210.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q8OORg/u" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-82361bcbd8fso2997437b3a.0 for ; Mon, 02 Feb 2026 19:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770088810; x=1770693610; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=uvv8w6qOpO5nJgdQm2rHSg/0QYZfhLcS6erT6wL/f8U=; b=Q8OORg/uIyhPul1juebvj0ffJ2XikK/WPiIP2ieate9jcmkW5mh5PsGzT+URErueLf 3CNGzBF4ko9P/7K7UGNZZp+N2MpburD5XnVPbQvggGhtiL7FugEG4UjIl4FDpWjxo0MM OEUNKWxsA/9Td4ckeBrXoz13uPiQ+bcz5SlP7CsSP0mlRMAQM/EO6WawCrEYI0yytsUC aDBRf2XHjKZMzX0hl3emgcF26vkgguXz022UW4B9ANvC17Xazp8BNoc1x8Q/AyJPAdM/ Xgq3zycCZNTV4P9mtEgtv5gWNK1tg+ZK0YRI8rxNi3yTRa+jstNY1pnTCMq5IIqFv1pZ j5GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770088810; x=1770693610; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uvv8w6qOpO5nJgdQm2rHSg/0QYZfhLcS6erT6wL/f8U=; b=Ql/qQohDUjq/8XJQ0BcCrPH3dPOfE+U42tB7j1hRQ4/d8f3nJtHBbda6lDINBTI6P/ b+WkKhsSgzQHsiy7gD5XKHYVS78av4HAIcJbpTfzduQ+8livN9ouBSK6pygxNNvnEps9 zXVDceDGpb6c/sKGWsnY1UQK0tYIjmouHQdGLfjCbxTPo5HXYi+pz5gxxnNcHcMw9Aii zQ7jRArfmz2arPhc3OWlChXBYpkwySbDmCYejANHZTL4d/FGFMCSQ6aUYQD41TOEFuUx z7C5mRljcV7vBRkLBWFUAPo8EmZ66WGnsFKGQBzbFIyTICNhDrnK6szzwzEVwgE5Xu8t b85g== X-Forwarded-Encrypted: i=1; AJvYcCXiVzVZKE/QIpjBnhe7yZ9AEBh9bke313JTz1GRIDawsTL3slhSYMNWsBB6E70SL5P7A7mPnB/KU/8ypDs=@vger.kernel.org X-Gm-Message-State: AOJu0YypwrTEtU4a62T9ysNwhx8DKKQX4RzZoAO+BIBvxwYfOiNRGrvp lVm/KLDKjrjKOBHMzILkLTQ2gNq8GPwAIfHMzKw7mGCkuw/MWbx/LcYB/EYdjNdz X-Gm-Gg: AZuq6aIfvvwODE3ptAVjqIpbYKEhm6+JxJXE+DiOmx+BQuxH/1K1O1v1d4Q1S81M/P9 +WHaaQTLVh5zZAhJ3fMSh26fHN5mM8/K6Vj2BbMa2m2Zn/2l00/+hYnaHRIjbloff3RJk5WC8JX 8IKgaL3cvdq2YOn9XTFFwG3zBs7LrYdCk1rrH+vEEFGZXmD8URvJivK0e1ZyzXqVC5GA9dPpgAp 8DyziPn+Ona+nvM1bBKFwxrzOzhFJLCXucUx98xDdvuqRuIZ/L95SDpqq/Yg1EQ6Bl9wkwdjfDh uwUSOvHXAfEg/GXkYRPd0tMxiREISkJ8QhoSB/3NXqj9zWFUf8M++L/6yMpijvVKW+3l+JjiFG+ NU6MzfYoyB1JQiK9POKe5bbfUIwSaux1rlWRqUBIEWzxI2E8vNh2KE/X4xEjrWDDcnaIEx6m+gI SMtXQfJsvga6l9gJvwvkmB4aylaSg6v/scY8MpUmr5bePpUJyKNbZBt7PBbNVs11e2bVhzFWpVM 34VDP685kPLSkrkn8eFn4ADiMgoSq9+mVsG+QhZ1Tm5aRek4Wj2faGZLb96BLL7lqsE X-Received: by 2002:a05:6a00:2e09:b0:81f:7db2:89db with SMTP id d2e1a72fcca58-823ab9853e6mr14526507b3a.68.1770088810308; Mon, 02 Feb 2026 19:20:10 -0800 (PST) Received: from 2045D.localdomain (120.sub-75-226-39.myvzw.com. [75.226.39.120]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82379b6b277sm21511394b3a.29.2026.02.02.19.20.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 19:20:09 -0800 (PST) From: Gui-Dong Han To: rafael@kernel.org, pavel@kernel.org, lenb@kernel.org, gregkh@linuxfoundation.org, dakr@kernel.org, tony@atomide.com Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, Gui-Dong Han Subject: [PATCH v2] PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races Date: Tue, 3 Feb 2026 11:19:43 +0800 Message-ID: <20260203031943.1924-1-hanguidong02@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" dev_pm_clear_wake_irq() currently uses a dangerous pattern where dev->power.wakeirq is read and checked for NULL outside the lock. If two callers invoke this function concurrently, both might see a valid pointer and proceed. This could result in a double-free when the second caller acquires the lock and tries to release the same object. Address this by removing the lockless check of dev->power.wakeirq. Instead, acquire dev->power.lock immediately to ensure the check and the subsequent operations are atomic. If dev->power.wakeirq is NULL under the lock, simply unlock and return. This guarantees that concurrent calls cannot race to free the same object. Based on a quick scan of current users, I did not find an actual bug as drivers seem to rely on their own synchronization. However, since asynchronous usage patterns exist (e.g., in drivers/net/wireless/ti/wlcore), I believe a race is theoretically possible if the API is used less carefully in the future. This change hardens the API to be robust against such cases. Fixes: 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") Signed-off-by: Gui-Dong Han --- @Rafael J. Wysocki: While studying wakeirq.c, I noticed comments for dev_pm_enable_wake_irq_check() and friends are outdated. They claim "Caller must hold &dev->power.lock" and limit usage to rpm_suspend/resume, yet pm_runtime_force_suspend/resume() call them lockless. Should I submit a follow-up patch to simply remove these restrictions or complicate the text with exceptions? v2: * Remove the lockless check and perform the check protected by the lock to avoid races, as suggested by Rafael J. Wysocki. v1: * Initial fix attempt using double-checked locking. --- drivers/base/power/wakeirq.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index 8aa28c08b289..c0809d18fc54 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -83,13 +83,16 @@ EXPORT_SYMBOL_GPL(dev_pm_set_wake_irq); */ void dev_pm_clear_wake_irq(struct device *dev) { - struct wake_irq *wirq =3D dev->power.wakeirq; + struct wake_irq *wirq; unsigned long flags; =20 - if (!wirq) + spin_lock_irqsave(&dev->power.lock, flags); + wirq =3D dev->power.wakeirq; + if (!wirq) { + spin_unlock_irqrestore(&dev->power.lock, flags); return; + } =20 - spin_lock_irqsave(&dev->power.lock, flags); device_wakeup_detach_irq(dev); dev->power.wakeirq =3D NULL; spin_unlock_irqrestore(&dev->power.lock, flags); --=20 2.43.0