From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7B0B73B5854 for ; Tue, 7 Apr 2026 13:57:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775570273; cv=none; b=LU9oqPjacLl2AyXT+seog4uk9FZVmhYFpmseMYt/WigTp7kV1uJOYLAjSpT+/vsc064/XADKn3K3h7F03BN6ISdGja/GOqj9IWtNH2XZUkp1ACr1lbmDCSZA+Td1vtUrjaUXHLWoOE3vC3EcYyZnGh+MPAZBvTPeQGRjc5DZo4E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775570273; c=relaxed/simple; bh=JW5sUUpMm0S6IPSUW0Ig9aHlpJ466PlG/4QwfjEJ8c0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=bzLad414iYPTdXxuHFRpulnUWWDPRKQwiArA84M8kOa+v8azJ8bGL6GLuSzQW0A034zr+mfMnB8SSu4fWFoMDZ/zd7RkYw4FnTVr72JED2hiDdrObxb7IsdiTh26DLjLE9e5KBInMZjHJy7nRcpImQCKPymZ1ScdY2ZFkl9GR4A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VCOHHGdT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VCOHHGdT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94857C116C6; Tue, 7 Apr 2026 13:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775570273; bh=JW5sUUpMm0S6IPSUW0Ig9aHlpJ466PlG/4QwfjEJ8c0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VCOHHGdTTyJbY/PWh9w7hRodrXfGham9Nhj6cJRy7z0stVP0TOe2ZVtpsMOPWYfF4 IZkMpQuR5pJ7daEmxUu09KvgWcbjuycqdgqmlygTcY4U4mxXUt3un/cy7fue1Stxx0 VthknSOywNyhPnjFxMih/l1CRn6sul++4+Gy2QSheZRXlDNF+peUUtqvnZBy/H+bgE hOkP3Jg9GwBG45I1kmxFKWL6eIugHMhrIl5jU5j7XaBbjHVmidFaoZXS/DJ6kPlbZk WU68mzTTbvq0oXVv6QQhO+AYX3acF5vCxj5GiJAZbIGjVntUCNYO9ozbse95ueBhPe n/6w0qoE0NcwA== From: Thomas Gleixner To: Zhan Xusheng Cc: linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH] alarmtimer: Fix use-after-free of timerqueue node in alarmtimer_suspend() In-Reply-To: <20260330061559.8997-1-zhanxusheng@xiaomi.com> References: <20260330061559.8997-1-zhanxusheng@xiaomi.com> Date: Tue, 07 Apr 2026 15:57:49 +0200 Message-ID: <877bqi6ffm.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Mar 30 2026 at 14:15, Zhan Xusheng wrote: > In alarmtimer_suspend(), the timerqueue_node pointer 'next' is obtained > under base->lock via scoped_guard(), but its members (next->expires) > are accessed after the lock has been released when the scoped_guard > goes out of scope. > > Between the lock release and the dereference, a concurrent timer > cancellation on another CPU could remove and free the timerqueue node, > leading to a use-after-free. That's correct in theory, but it's a made up scenario as this runs during suspend after all processes which could remove and free it have been frozen already. That said, I have no objections against the patch per se, but I'm not accepting the unrealistic argument backing it up. Using AI is fine, but taking the output at face value is not. Thanks, tglx