From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 E02E739F184 for ; Sun, 12 Jul 2026 12:37:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783859851; cv=none; b=GUu+5Rj0g9WaLjNrryYa600BWaAOBuhGnwEe8jzbddLurujMvReQcdh8PD7AI/uQQrS2ZTWDMxcIvjnkti0S7l4QUiASI4lyAsx/c9hfL6q8tlhKiWdbps9ECu1Dir76rtPM6+7fHSjCD1tryosAVEW7k641CCNhXswxCI/Cxi0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783859851; c=relaxed/simple; bh=g7yWmuczWtbYlfQJA2y0trl2LE6gztc6WcpaqKhAyuE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=LZDERXHRjQ8fS1s/N0iZt5YkEI9bzPxNZ9RvsNRQXyJqkC3u/13d9/8ck4rO7Pk7RRzqmYOGS3Z+SO4mMeKICsuVh8Cq7XpOe6f3s2tRzn1ibbgkd7Uo3XWkUvt+94ZSYUKzWvGeR2+Ko64nK6t5LzHNQ1tZRCwoMOHsaFCbmPc= 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=LEQ/jCla; arc=none smtp.client-ip=209.85.128.51 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="LEQ/jCla" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-493f431e317so21790485e9.0 for ; Sun, 12 Jul 2026 05:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783859846; x=1784464646; 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=wEMsU51i/WwRT9EUJxt87IiRt2e91AKiv08Nq7CHthI=; b=LEQ/jClaTtWPckh4xpcr/o2h/CmtraxTAWJYlSwMMKt4IgdWbDA8jtZiFFio7yl/0q VbDL+xjlvDA91bKQbVrCnGAm8eJVxDby5HvuEDAOZss+rDvaJ8aZiJ8ySc4loEEfOM/q Fn6F2VfSb4PZsRv/+ctvfeMFz7hWGdlNRHp7zpgRzmj6FgoSf0/tGoZEeP6Wi5Ecuqzg 8oRiV3OHn5G49jOKC3cqrGedqJUoU7/HhkPz22g0Qp+yi4xhUKAipjmFBn1kWZFXtV37 QQRti4h3W39u0LhWkTOyEwkAH5adJGe7OTjeM4Fw+rgqCl2k2JRlJZLZmuf+HcxOTbMm FLpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783859846; x=1784464646; 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=wEMsU51i/WwRT9EUJxt87IiRt2e91AKiv08Nq7CHthI=; b=sEfzovyMf6v5sQ2ZttJYeyDAC2tKk+LgDoMKXCYRBdzRsiNETn74UG6tvZ4ZgJqLit YdHxJZm0yc+bdT5UWtT2OCFRMdKCdJbbe7SqZrba7PYxi0Y5L6T8B3Snx1TqMz/0Ggc1 WkJhGfkjzi4edMjqAQPHOU3JmyPbErr7lDPpnm/GRSrBvPORIDFRdREh5+1aV8lE4F+e hXVRJw6rVYAg5a66HsI1WgSsF8VyL3zwKC6xcRt6FmilMhSU4BM3yiiRgAsdU/kXlcxe VFB8qvV6CXD7FgHm1IkLew3uHI+JVYxgO3Bm5RlAPJuI+LGQu+MAWVl4mgb0xntM4pv9 Oemw== X-Forwarded-Encrypted: i=1; AHgh+RrWVZclMh721HajBbhX+dKZNUf58BofflKoQPnABm31TsJV6cw/NjYd1ALYWUXbdY36Dx64wyRVLJ4Opwo=@vger.kernel.org X-Gm-Message-State: AOJu0YyuQumCYUusrNW69jy90RoubbIrHsnD7s6+SM0zotHXrRXlSmz/ pt2sgKmEA9nNPK1ziXbEwN6M6AcNSvT9voqzpfUrSJRdqhGJO96t8NLc3xJFFn4+V1M= X-Gm-Gg: AfdE7cnAVzO1xxgUlsldcxoLsVw0+iwe3GtxtYxeSHkEcAUIhtMz4wcAVlv1WkseYBx yF3zUOhnyBUoGb65m2Q0m6MgKdosXKhhtby+3fNku4SmmGki9bvv8Bi5ncj3FeHID47n2i8SuEN vs5XlNgM3vv5cBf2BMqYW2mL0I9iqN/Q28+gzDnCR3kJgiDKn8Mn8+NosLPhUKO52pPw1j/yM4Q i+tYYfEpCWHVAwsd5oG1gIYoVMMHHAGg8moIRLbnwUZIAXDVi65Izm8qf/UDMluxXJCldmGiFeU I7GuXXl7iBLzE8adn9ae5b0JNFddRBCHfCn/JsnOoQ6GK7IDgXjYEnTDtEkOurfLnr0ficFnxM9 iAtPu5h7qeNhY+kUUFq71w7zIIWyXXk2uEKDcmk3opjy+0fcuC9zM5U/cczkhg2NSxV9GoWiCT4 zviCJpcTt5A7Qyu4A= X-Received: by 2002:a05:600c:705:b0:493:9661:f55d with SMTP id 5b1f17b1804b1-493f8826bf7mr39689255e9.30.1783859846182; Sun, 12 Jul 2026 05:37:26 -0700 (PDT) Received: from fra-x8664 ([2a01:e11:8000:43b0:96d6:566b:35c:7b8c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493eb6f3c42sm280280485e9.1.2026.07.12.05.37.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jul 2026 05:37:25 -0700 (PDT) From: Francesco Magazzu To: Lyude Paul , Danilo Krummrich Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dan Carpenter , Karol Herbst Subject: [PATCH v2 0/4] drm/nouveau: fix list cursor use after loop in the clk pstate paths Date: Sun, 12 Jul 2026 14:36:12 +0200 Message-ID: <20260712123616.1180830-1-postadelmaga@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: 8bit This series deals with the three places in the nouveau clk pstate code where the list_for_each_entry() cursor is used after the loop, plus one unrelated fix. They are exactly the three sites Dan Carpenter listed in 2022; his patch for the first one was never applied and the bug is still present in drm-misc-next. Link: https://lore.kernel.org/dri-devel/YvSkKAdk8Pe0g2K9@kili/ Only patch 1 fixes a bug that can actually be triggered: nvkm_clk_ustate_update() takes an arbitrary pstate id from the user and never checks that a matching entry exists, so if it does not the cursor ends up pointing at the list head and the code reads past it. It carries a Fixes: tag and the credit for spotting it goes to Dan. Patches 2 and 3 fix the same pattern in nvkm_pstate_prog() and nvkm_control_mthd_pstate_attr(), but neither is triggerable as the code stands: the callers of nvkm_pstate_prog() clamp the index against clk->state_nr first, and nvkm_control_mthd_pstate_attr() already rejects args->v0.state >= clk->state_nr before the loop. Both are hardening, not bug fixes, and they carry no Fixes: tag on purpose. The point is to stop the two functions from being correct only by virtue of what their callers do. Patch 4 is unrelated and is a real bug, though a modest one: nvkm_cstate_prog() overwrites the reclock status in 'ret' with the status of the voltage/fan restore calls it makes afterwards. The only consumer of the return value is an error message in nvkm_pstate_work(), so the observable effect is that a failing reclock is never reported in dmesg. Compile-tested only. All the affected paths are reachable only by root, through the 'pstate' debugfs file, so I could not exercise them in any other way. v2: v1 (2 patches) was sent on 2026-07-11 with a mail client that mangled the patch text, so it did not apply; it is resent here with git send-email. This version also adds the two remaining sites from Dan's list, and the Fixes: tags to the two real fixes. Link to v1: https://lore.kernel.org/nouveau/CAHwn+vnw=DD=j7umFVdcr8-F6yUz=iM+3yfA+HcHKXJwpNrHRA@mail.gmail.com/ Francesco Magazzu (4): drm/nouveau/clk: fix list cursor use after loop in nvkm_clk_ustate_update drm/nouveau/clk: don't use the pstate cursor after the loop drm/nouveau/device: don't use the pstate cursor after the loop drm/nouveau/clk: don't clobber reclock status when restoring volt/fan .../gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 8 ++++- .../gpu/drm/nouveau/nvkm/subdev/clk/base.c | 32 +++++++++++++------ 2 files changed, 29 insertions(+), 11 deletions(-) base-commit: a284476db2653ae893f46cbea408eb412db54eb0 -- 2.55.0