From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f178.google.com (mail-dy1-f178.google.com [74.125.82.178]) (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 AC7B719D081 for ; Mon, 26 Jan 2026 03:30:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769398222; cv=none; b=ihzAoMlw+5dFZvkD9fgpph/5RiOIij+OfU0eQdEBhJlXWfEyoMHRT+IgoMlGSl3d/+dx0hXxI8xoBYZ4xdcGNXgCeg2Tg24iIpd6ovtGsnSeQKWIB21KT5L+fl923/ilfA311Ev0K5gPQjwG2JEDRhQFkyBfjazTxSQLnwJjtIA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769398222; c=relaxed/simple; bh=odnHQjFmvL9q0KAXvfxM5lKxhjvove08qebNT2N/TYU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XXQ2eXp+7kCyAPb2cJr2GQA/cjuMPSRzo+e/ECm/jwYJCkeDsFLoFuyQaahrZjzwsKUqnUiBR50fEblxIZMfsJLuSdkk2orJNDZE276JxYqEnh1KXiojWTaouT0+xChKMwJ+gV/NQTGuTyan64NEOVhUNgk8+EzirKIWsNyODHs= 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=SQjsEPuF; arc=none smtp.client-ip=74.125.82.178 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="SQjsEPuF" Received: by mail-dy1-f178.google.com with SMTP id 5a478bee46e88-2b71557299dso5703941eec.1 for ; Sun, 25 Jan 2026 19:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769398220; x=1770003020; 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=ALi30XfcHcP7oXf6VT++jD7PYo4ntaFHOPvpKBXFeRE=; b=SQjsEPuFoIIv7vmZ7ST28ifCdVexsZ28ScvlTDN52PrkEH5NlA2sQIOUK10k3oAJL3 pa0k6jbiEkAgqUPf8wmr9U+BPL/DTTcKV0Ck2FHi+UzTTxlTuvkprKJNuENYnlPqv2qn A5N+ybjv0TCQ/eO5lXJ92ICEjxvZw6wV+v4kMVRBxhuvTG7GB7iqBadSKun+Zwqfn0vt Ng3CQENVMvyD9652ZpFMzEIfa0f3rS1Hh6HCeosfUMmsNDhnNoakjk44c8WyD+LrdlRT WVBmufytixsYpL6pONB6BKDk1PEcDlHuCFCV81DB9Bvz5zkzeYJnwDWgHu5A0gTgdjZs 41tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769398220; x=1770003020; 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=ALi30XfcHcP7oXf6VT++jD7PYo4ntaFHOPvpKBXFeRE=; b=sDPxC14HWJP304CKlaaI92Fi9S6I/OLfLYn7ruwgbulTejrYlKuqL9EZ7wNx/fgFee 2tmtnUSlRUjHV56kcH4untD3egQv8gnhE6qkNul4/n/KP2A2nreMD8chkJTMZWT4HSj0 jzuPhMX2QOF5py64Uddb48q2hmkh7vzESU+DsAYPGLxbDc16uxEPptdq45rkrsmFibi+ SkiI+lDKrLKow8ZMjMSEl4sNMAOvhThxpy9QIWGp0Y7mhb4YcsZmTmZ3AbKT4xjb8dlz gEMHKSZQAWv7oDkaEq1CrGb8dXPT3b64k9h2Rg360GigPG1/aXfwHeBSdlzDRr899BMU TWbA== X-Forwarded-Encrypted: i=1; AJvYcCUfSyeOzc/2/O24CuT2NscP4P2DP6yI2WGl86DLP6OWPpGzgpD/dxtpx8w885rd4ecKRwojOAQ8N1yKIbs=@vger.kernel.org X-Gm-Message-State: AOJu0YwXhIosJN0WH8cTuTifHHA+NuStruizhLFyYP0OQU6V0+lnQ3Nt 3zpDMfAqm2SGfQx7+6C00i23RmfUW2RryBg60lCBLyjsoDfAEW2tFT16 X-Gm-Gg: AZuq6aJqgcLNggSUHKfa+zwhPDEhK9sPqmW33MDtar1w4M++hOubSeBKvmVlWMcVsC+ geWlb3ylAKTkMAv3T3fnpbmrjEGRDvLEELCp0SM7e/6Mzhp38GJMgmVF/1e67FKCj/sB67F/AWn XTCbfX9/2exhaI4+Pxcr61AuvhzmUomdWg1Sfy6lWs/lKZTzcIc9jyvnrLPnGtU/3DztwMd91p5 dhbsi4RIot9AajsnWqMAx7LCz4x7CDjbXUfU4leLlKtyj8IYZIZbrox4QX/X4AStirknaJF1+e6 IlgeH8ZArhhKPV+nChaFlnQLQ1rdp9dVby0xBrMIlUcZlbJTE7nbXZFfLLRLnKLD14luwB9wO40 GUgjMqrNQEqvJl/MGpryw20jzhLs0Iovc2RqlpFZAaMEv+1WKeiAGLzSeL99JEje85B4vMsgjmk MnGzI= X-Received: by 2002:a05:7022:511:b0:123:345b:ba05 with SMTP id a92af1059eb24-1248ebf7011mr1465124c88.22.1769398219711; Sun, 25 Jan 2026 19:30:19 -0800 (PST) Received: from debian ([74.48.213.230]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1247d90cda6sm15429026c88.1.2026.01.25.19.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 19:30:18 -0800 (PST) From: Qiliang Yuan To: dianders@chromium.org Cc: akpm@linux-foundation.org, lihuafei1@huawei.com, linux-kernel@vger.kernel.org, mingo@kernel.org, mm-commits@vger.kernel.org, realwujing@gmail.com, song@kernel.org, stable@vger.kernel.org, sunshx@chinatelecom.cn, thorsten.blum@linux.dev, wangjinchao600@gmail.com, yangyicong@hisilicon.com, yuanql9@chinatelecom.cn, zhangjn11@chinatelecom.cn Subject: Re: [PATCH v3] watchdog/hardlockup: Fix UAF in perf event cleanup due to migration race Date: Sun, 25 Jan 2026 22:30:12 -0500 Message-ID: <20260126033012.934143-1-realwujing@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Doug, Thanks for your further questions and for digging into the 4.19 vs ToT differences. On Sat, 24 Jan 2026 15:36:01 Doug Anderson wrote: > The part that doesn't make a lot of sense to me, though, is that v4.19 > also doesn't have commit 930d8f8dbab9 ("watchdog/perf: adapt the > watchdog_perf interface for async model"), which is where we are > saying the problem was introduced. > > ...so in v4.19 I think: > * hardlockup_detector_perf_init() is only called from watchdog_nmi_probe() > * watchdog_nmi_probe() is only called from lockup_detector_init() > * lockup_detector_init() is only called from kernel_init_freeable() > right before smp_init() > > Thus I'm super confused about how you could have seen the problem on > v4.19. Maybe your v4.19 kernel has some backported patches that makes > this possible? You caught it! Here is the context for the differences: 1. Mainline (ToT): - `lockup_detector_init()` is always called before `smp_init()` (pre-SMP phase). - Risk source: The asynchronous retry path (`lockup_detector_delay_init`) introduced by 930d8f8dbab9, which runs in a workqueue (post-SMP) context and triggers the UAF. 2. openEuler (4.19/5.10): - Local `euler inclusion` patches moved `lockup_detector_init()` after `do_basic_setup()` (post-SMP phase). - Risk source: The initial probe occurs directly in a post-SMP environment, exposing the race condition. For openEuler (4.19/5.10) kernel, the call stack looks like this: kernel_init() -> kernel_init_freeable() -> lockup_detector_init() <-- Called after smp_init() -> watchdog_nmi_probe() -> hardlockup_detector_perf_init() -> hardlockup_detector_event_create() In mainline (ToT), the initial probe (safe) call stack is: kernel_init() -> kernel_init_freeable() -> lockup_detector_init() <-- Called before smp_init() -> watchdog_hardlockup_probe() -> hardlockup_detector_event_create() However, the asynchronous retry mechanism (commit 930d8f8dbab9) executes the probe logic in a post-SMP, preemptible context. For the mainline (ToT) retry path (at risk), the call stack is: kworker thread -> process_one_work() -> lockup_detector_delay_init() -> watchdog_hardlockup_probe() -> hardlockup_detector_event_create() Thus, `930d8f8dbab9` remains the correct "Fixes" target for ToT. > OK, fair enough. ...but I'm a bit curious why nobody else saw this > WARN_ON(). I'm also curious if you have tested the hardlockup detector > on newer kernels, or if all of your work has been done on 4.19. If all > your work has been done on 4.19, do we need to find someone to test > your patch on a newer kernel and make sure it works OK? If you've > tested on a newer kernel, did the hardlockup detector init from the > kernel's early-init code, or the retry code? In newer kernels, when the probe fails initially and falls back to the retry workqueue (or even during early init if preemption is enabled), the `WARN_ON(!is_percpu_thread())` in `hardlockup_detector_event_create()` does indeed trigger because `watchdog_hardlockup_probe()` is called from a non-bound context. I have verified this patch on the openEuler 4.19 kernel. During our stress testing, where we start dozens of VMs simultaneously to create high resource contention, the UAF was consistently reproducible without this fix and is now confirmed resolved. The v4 patch addresses this by refactoring the creation logic to be stateless and adding `cpu_hotplug_disable()` to ensure the probed CPU stays alive. I'll wait for your further thoughts on v4: https://lore.kernel.org/all/20260124070814.806828-1-realwujing@gmail.com/ Best regards, Qiliang