From nobody Tue Sep 29 07:41:15 2026 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 04FC5440A26 for ; Mon, 10 Aug 2026 19:23:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786389842; cv=none; b=II91yXImROLUHM2OnRKSAF8irgCh3fhVhixF6jxDvsIVHMN1nZiDLXDlJlJQllitpY76UTrFO7x52Yc0UPBu0io6l/kl9PjVo39kqHOu5yZGTLTe9Vz5DHbHrfaxdqcxMkwcK/wMfzzucV1DwRmoWfCZgDohU/TWgaSCm3vb4FE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786389842; c=relaxed/simple; bh=cmcBRihOWeRm2A62QThP0eO/LBtlR8g441e00NZTPlo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=jY/Hd6SB/oHBZ0ra40LjoLiLxqPKq8dPYS7Rr89fJhNUClTJb6o2YvW6BJ0M4oHHvRePlnqo7InN0JZ33M1SD9mG4GFFZgMRTSo+nBTmaYYib3RTZbxHXQ9mn4x+IzcH0WCoFQUl3m397QOd7rgdpnPNTNXuKwFRXBWWZUaed3U= 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=Y/larUZq; arc=none smtp.client-ip=209.85.128.53 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="Y/larUZq" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4955aa106b1so19956505e9.0 for ; Mon, 10 Aug 2026 12:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786389828; x=1786994628; 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:content-type; bh=13S3RQKmhLPmbcYWBBgpmRSfPBJG5AWZF61QpVweiYo=; b=Y/larUZqR5K2ccIQhpp68eGBgXlQ8j8BAGPW16fpKCXBzxW/mr71ZdP36zqofYv5q+ bnHcBBW4pU+1YhtXmtRRwCw3pagGLOCeD/r0T/aFkPYDwyU1ZCSD932EyKtqSC86/LR7 pRdLrM+xwqls8oJwFL94UcyW36Z+1aHpZXo2uPB3QZZRFDWLVYM3x/Jyzh6MydFDAQ5j 3DdQKZiE+6VP8jAKScL8bgpVxdn2amfZHkn9JA/d7Rz7KbVljBu6u3xmb4BSmXpW0ZBj hWMcOXbaUWuXfhD3vwf/ioRkFedW9K/9jjlb664VUM255isqhhoPKjY2v3DP9yV5y5mQ V31A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786389828; x=1786994628; 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:content-type; bh=13S3RQKmhLPmbcYWBBgpmRSfPBJG5AWZF61QpVweiYo=; b=GLvjfaaY2E1U0JKwWHhT6NW92Sap1YTWzv84gzTgiR1oeddjRWsopZQ0xhjtP5OgPd vUnsgGONht+RUK92XHa5w+vRadbSdcRl2aMZyzPx53G1N86idEw23sLM0HI3PiFdDHes NSkwsiEPkOMBRmFITM2KRo6TTvAiba2zd+bum0Di4unk+7hbL5KuOO/kNTetpx1+vciS Y/KvCgQvfS3JXjuIBRvEiFDm4wm43BNPLcv1M28VmpKBG12GJdMwfxwgyhxZG16al+xy 9o8QmKoQjb6WeeHtmrQFx4BMvEXqSSr6BN+r5xJ57oKkQwwqOkSC43Cb+idRyG7V+ZD5 wd5Q== X-Forwarded-Encrypted: i=1; AHgh+RpJIR/uG7fFy6fi77AWT/galU6WAnnycQ/zi0snrBY2ZZkeHEaC0lMQBnOAobf1z8QXYTjwxTz1wcHUbz8=@vger.kernel.org X-Gm-Message-State: AOJu0YwT73OCOYot2+Z28JlA5Dmks7AVr6Cd5fm6dEIcQsRe6DxrSYal FU57Q8i32ejU3DuOAJaJCvIK4Ac3F/4ofhsKbWtLsIwPlw9qYJ6gYwLa X-Gm-Gg: AR+sD10EVLjaqJjOw3h2f12Q5CzYNhbOltP8ev3ARF/Azvo11nRDhTEU9EmngR8cl19 LojTxAsfNenWhr/FYewOROKIJ986tSTSEjNpSMsdd+sEba6AlgSg15xRAb7K+zmbZg7RfruNP1B 33jgFsQ4eyaqKQXnnUN8sNLRpco4nke7Py29wLROL3Gq7DpynLz9s0ARgOHqW391lM0tvjnVXhD HOtA2y7vIO9l1FvVBNfCqTq7qDbQJ55RjzghmQqAPfc/20OzU6mwkFL+Zgu2d+g1z1I4zUHNDmK /nXXKs3TLNeo2gTPtBhFYN2g3O4f+LHSs7CFFy7VARDdl1yYy8of0Tbhm9ETHyHDVjQ12s1pzxI 9kSF9U2pjKT/eKmBqglHSz4bptLs9bZJ867lkhOXUXh1qeaS5IC7+5IhjZByBWkoN9gxtMHulAG BHBGSer86CEtWzxNsiNtqvgRdo6yuE+JGedYX7EB4gNgmUqRO4VDsDnfJpIUDKabJPe204756QD yyGlS12sylknIfxYSJtQoV8dTkVlyc= X-Received: by 2002:a05:600c:1548:b0:497:ff73:68d5 with SMTP id 5b1f17b1804b1-499726dacc9mr43965065e9.0.1786389827363; Mon, 10 Aug 2026 12:23:47 -0700 (PDT) Received: from prometheus.tail8f5cca.ts.net ([85.11.110.37]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49974170572sm12497975e9.15.2026.08.10.12.23.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 12:23:47 -0700 (PDT) From: Szymon Wilczek To: Guenter Roeck Cc: Zhang Rui , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, Szymon Wilczek Subject: [PATCH] hwmon: (coretemp) Fix core_data leak on CPUs without PTS Date: Mon, 10 Aug 2026 21:23:44 +0200 Message-ID: <20260810192344.3733721-1-swilczek.lx@gmail.com> X-Mailer: git-send-email 2.55.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" pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles. Fixes: 1a793caf6f69 ("hwmon: (coretemp) Use dynamic allocated memory for co= re temp_data") Signed-off-by: Szymon Wilczek --- drivers/hwmon/coretemp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index 6215ea49faaa..ab9c8cbf887a 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -650,6 +650,7 @@ static void coretemp_device_remove(int zoneid) struct platform_data *pdata =3D platform_get_drvdata(pdev); =20 ida_destroy(&pdata->ida); + kfree(pdata->core_data); kfree(pdata); platform_device_unregister(pdev); } base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5 prerequisite-patch-id: 1c584cb0c0bb331df7601073d4f307fec3fcd585 --=20 2.55.0