From nobody Fri Apr 3 12:44:42 2026 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (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 2A64B353EC5 for ; Thu, 19 Feb 2026 17:14:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771521260; cv=none; b=TZFrq/K7Qv6x8pweaxSKGOVOLNhPHU4socQfnAa7Z44ARBVMWhzFEBT3Y3bU6Gk2Lbo+/y/QjW7FZs19IpSxp6k7bcZRHmPbTjBIklVFqstQNDjrKSAKDOuz8OmRPu3sEiKiRb25maA9YHRtiYimC3AoYnxg1iA4Q0zcwJkYva0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771521260; c=relaxed/simple; bh=Hkj+3H7Z8a3D2Y8tRX2SbgMdeMF/kuGLJMd704mftHc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ZNcc+FexSl54He2jm7r7S2wPEj8+pJgZE2oOoLb4kkMkULsYqQ3sMsZplOjUcO6L6BxqM/4qdQ9WgX1J672Djl9Xcdc4hcg80/VQDmEVtNpadC0lS2qk9I2TczCBHC7+jGco8lV7R4qRpJK5TqyR0xI9+VicYg4vm30Nm6vY5Hw= 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=OTSVdSNV; arc=none smtp.client-ip=209.85.210.180 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="OTSVdSNV" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-82318702afbso986232b3a.1 for ; Thu, 19 Feb 2026 09:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771521258; x=1772126058; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=QKKfl8PT/GCaUO5UcTwQ5MiYDnn0Vh3veSo7jvr1Ic4=; b=OTSVdSNVuwBDyXp3D/0mYMOlcZ/IMRRwNikzboDFnxJPVV2zhMW7RKKZgUclNIQXDg 7jzvPDlKIG0kRzsfa8L3IwpnM7wnF1+XfsxKv2pAgjANZ9fv1qDdOdfUPT95aLQCorng ZSLElhkX3S6L28YVBEnvfkIg3Ynaba9hm34SBOrqeNcxQ1zlxrMfkxyiu4Vib9ydiIV0 +Dpz+Kyn2QHw0DeC1yjlpg3wtvrVEUbKlC0V9gmjVIccqXbqjL+2d5sV8ZuYpREEnEZO 5EMcqLTixUWA0UKXvNBQ7VS81ZCKuv/pS4dlgKcMqGCY1+/1AB4Ssj1HAZn8kKdodPPc 1i9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771521258; x=1772126058; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QKKfl8PT/GCaUO5UcTwQ5MiYDnn0Vh3veSo7jvr1Ic4=; b=iviF0TsrrVbix3yX1QE3Fb736nFgwiR4qI30PPfjHJvFAtmxg1Aq8zf8+iYb8mFBXg dIZ+/qn9BapytxZEa1uatEjoLeA8kxo2zHKk1ksVvWMq0c7NwycJgt3Z6aCpKpYES3qR EEzQa5lEG67Z/XIY5KpoRJ6h3bWBqOiN66I1dJOJ7qZNylRUjbdd6PCMUFc+rsIQrXk6 gqQdvCsr4lzUlUlGPZ0f5bJhCERgccsKlFk5LmZ927ieFguI1PiNQhgun376wlrvHAad zA111IBzTEsxVvLFp2nebfX7LMghcNysDOn1hX1N0VafWYyxXyjsRFD87NvuB5GP6AY+ JRsQ== X-Forwarded-Encrypted: i=1; AJvYcCVQm4sKDVcA2Kj6G0gGByBGtn86u/2kCeZ6SUcNMWWMrqswbP6Z+rkqBBAdwZTHAGCxO+kFuKPyJ9OIVb8=@vger.kernel.org X-Gm-Message-State: AOJu0YxA9BhwIzBSljhMhPRH//qwVaQ350/5L6wALOBkcjPUBinTxzvN vctMV9bBonEhh6sYrPsaDHIzm3i3wGHIJUWc1NtoNa/4aXUpq3MnNvww X-Gm-Gg: AZuq6aIxrkffremxPF/Hofc34INx/zMMQX2D8t5ylJGhY5g/sx0dmCce9YYQrYcXCOK 0HNC4EiCgxInP5bh4INLDwt24w5YplPv5OeO6FgODTwS79jacyYiPJ9y5Y6w2mR9ks72AvgVQNQ foxqYQ01GKfO5wYMG0ZrR+Xgm9Z2BRv99zLeLnLs94XQtjBqhwZjdYIBBnE9VvbVhDYhV5xn8LR 2aPvGzW55DVSyj51jddiDqrJ6fUocusSWj/Hhs94/uI2y7B6ZlTTLG+ASjwmDWeBCJ7Qmr9CEfz /0bJsOzhuKRjnOBIkx/dOBzzweodirVu8joEJzPjOEAQG+yxKIT0s5VtjnwFOhcak82IiQDL58l OrnPHhCGcTU3NzYcweKLMEMAbur/rZiAJjcgDW0nHOgy7m8U8C6qCa6BYIgcw4F45kG17LPDEin +ltcORgg3YmsSu4T9TLQU0y7Lw7M5nxjjnT8I3P9SXLUHsaMrU/g== X-Received: by 2002:a05:6a20:cf88:b0:361:28dd:a9ff with SMTP id adf61e73a8af0-39483a5a85dmr17158114637.38.1771521258512; Thu, 19 Feb 2026 09:14:18 -0800 (PST) Received: from name2965-Precision-7820-Tower.. ([121.185.236.165]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c6e532fa2e5sm15895002a12.26.2026.02.19.09.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 09:14:17 -0800 (PST) From: Jeongjun Park To: stable@vger.kernel.org Cc: gregkh@linuxfoundation.org, tglx@linutronix.de, Julia.Lawall@inria.fr, akpm@linux-foundation.org, anna-maria@linutronix.de, arnd@arndb.de, linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, linux@roeck-us.net, luiz.dentz@gmail.com, marcel@holtmann.org, maz@kernel.org, peterz@infradead.org, rostedt@goodmis.org, sboyd@kernel.org, viresh.kumar@linaro.org, zouyipeng@huawei.com, aha310510@gmail.com, linux-staging@lists.linux.dev Subject: [PATCH 5.10.y 15/15] timers: Fix NULL function pointer race in timer_shutdown_sync() Date: Fri, 20 Feb 2026 02:13:10 +0900 Message-Id: <20260219171310.118170-16-aha310510@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260219171310.118170-1-aha310510@gmail.com> References: <20260219171310.118170-1-aha310510@gmail.com> 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" From: Yipeng Zou [ Upstream commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c ] There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer =3D timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer !=3D timer) ret =3D detach_if_pending(timer, base, true); if (shutdown) timer->function =3D NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer =3D NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer !=3D timer) ret =3D detach_if_pending(timer, base, true); if (shutdown) timer->function =3D NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functi= ons") Signed-off-by: Yipeng Zou Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1360,10 +1360,11 @@ static int __try_to_del_timer_sync(struc =20 base =3D lock_timer_base(timer, &flags); =20 - if (base->running_timer !=3D timer) + if (base->running_timer !=3D timer) { ret =3D detach_if_pending(timer, base, true); - if (shutdown) - timer->function =3D NULL; + if (shutdown) + timer->function =3D NULL; + } =20 raw_spin_unlock_irqrestore(&base->lock, flags); --