From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 D6D8B1E5714 for ; Sun, 16 Aug 2026 16:49:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786898950; cv=none; b=HFmjpBjQMppKVFiPkfA9Xly83j0w0s6KqMQX34GvoFUc6LthCrLPFbVWB9sbV2nrS3x3S6xNA5SPWrEtJchvwbkJQRS8DyNJYn3+u5oVlwULAZDKuieRyNW3Ox2+llRdXEH9iPOEvVwbqXBxB1ACtJzjngV7FANUZEeNxbUDhVA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786898950; c=relaxed/simple; bh=zwyhY8prj3ghW7erwkxL/jSt15Nmq/aKYIa2znd9RBU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=I+c0Yk8rNYiFOoAKEeNMXXbakGfVNdgS+kjmS2RLiOQMdr/lOFnPu42fwWsjM0lbPtx7Q9Gh99zRslVW9Y57q2vW8XE8APQfvKojzJSILXuRWoiRdgH0oRauualM8dPMINbWITDFE0jb9064VxrB93A009jYARRAOwlRL7xbgns= 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=fWWwlYNC; arc=none smtp.client-ip=209.85.128.54 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="fWWwlYNC" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-495502852d1so2096185e9.2 for ; Sun, 16 Aug 2026 09:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786898947; x=1787503747; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=h1LuoOEYRW0czN5Bz/p4SIeY+1XK0NUMWZ1zoBbq6Xw=; b=fWWwlYNCfbZo7BVZMz9XujPA6hqF1qHf7GGisgIg4Rqnl4drDNYQPCca7INld6Osdv NzDu9WEqyMyacE7h3K8V0zxVC+8KuShLJSmgpqOZN4Fd9xfSuWr0A8MDhRD0XvW6DxrV MCojliwmTDG5MR1aonEaGEaOqHuSDz1DZwFPJMZ/KfyLAeRXNKN9rGX77MLfVdNLIyeF RbAHypn9INEg4Nilb+X4/l3qg8l6HpLG5/pEZ7qfH3IUVhNiF/Rq49Uu9R2H1rND2toq r4zpLvlu1cwGFuuIFxo/7wQuaZ4oVQvHgQIO8dFHYhcY4Oqnw7ZPQ2e8FMwgnjosPcXv S5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786898947; x=1787503747; h=mime-version:content-transfer-encoding:content-type: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 :content-type; bh=h1LuoOEYRW0czN5Bz/p4SIeY+1XK0NUMWZ1zoBbq6Xw=; b=IP6YmQ/c/E1VpW72RyfFLi3kWBbn1zX7mh3exMfwPyROA0makRgXUEwc5AfiI1yv01 G+GFhhv+BlJDwi6/HyOAc0YKJAeu0oDjnitlu5GJkWIZ4dli1ppUe5yIAh89f0amV7a9 XnCfW+V7hpvlS6pwe3/x3i9hNVYlYvgROzd10slIqEB0OWnYseP9Hj6a81AY0Ig3N7vf FHnpeApg9Zim6/cfHehn5+ce6ajm+38XBiiUMTn6r50HgL+re33LxFH9zDyaR3EwbXe6 NztlvQ5+kcAg8JtmZlb9OpN4CIAL1hADVs4ijemwkcPPTH28ikeSDBEM8RTO9tMqbHxd sh8g== X-Gm-Message-State: AOJu0Yw48SEe6mQ7V/z0jrFLanAhZTN4gWNSJfvw4AygcqMnwOeipoQB HTlXtt0RD7t+vAIz53XVlg4cIsu0LUu19jp+xJ+ZSWMZaBoppWQ6xvXm X-Gm-Gg: AR+sD13P1bLt3alLCOkeouB0SBOi00frlumW9dgK7wgz+xws6egySbg4DNUmNjbtq+t RtXV8KP9vqU+OMBocswKj0ZSztu5OqzgUYwK3mRiL59IvDpTRdM7bCtNq953d6Nhu2GPu3r39NN q65LNmXWS+gsfHaXN/LMez8AFqjgvG2Yc0amWYJNbwBXOnBJ/csLtyLLAtjHz+FYaBQYX/vMa2P gJbvcO4yUz1c7f4aQkJSL2yryTtPqSsUzygk7Dvn705yOGJGQVmnhibKFq4MKyisWB0/hZeZKpZ gptMFRAXmzgoPauFw2u0O0LBqq9z4z+8IKyGXosKn/rr7ZKFdvva4Joc1VoPs2IYpQgPL7104ij zYiJU7M/ZPoe74z0gTD+TUJibHmYiCvPm0Wv8hHSCeQ18D1FRpEpCKenf4XkBqp6xb4mmI7++AP 5XUEAChaKlHk4yFeZDk5+K8xGUFCZQ516tBJyzL3iwV5q206rLi1xhKAJcOHVFNybMTCDp7X+lW NDCBwqbnlGWb3fQQCItobcPrmjoDonIm5vENs7TiM8n3UfG9qjp X-Received: by 2002:a05:6000:26cf:b0:46d:ff8a:c8e6 with SMTP id ffacd0b85a97d-481606f6d94mr14601663f8f.1.1786898946689; Sun, 16 Aug 2026 09:49:06 -0700 (PDT) Received: from [127.0.0.1] (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f21df13sm20760381f8f.15.2026.08.16.09.49.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 09:49:06 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter Subject: Re: [PATCH v4 2/2] drm/nouveau/kms: guard NULL crtc in nv50_sor_atomic_disable() Date: Sun, 16 Aug 2026 18:49:04 +0200 Message-ID: <178689894484.725775.7881685692020502024@gmail.com> In-Reply-To: <20260816131755.1B99B1F000E9@smtp.kernel.org> References: <178688574400.522643.6695278742335367229@gmail.com> <178688574402.522643.5471719764843371376@gmail.com> <20260816131755.1B99B1F000E9@smtp.kernel.org> X-Mailer: python-smtplib Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 > This isn't a bug introduced by this patch, but while fixing the > disable-without-enable issue here, does a similar vulnerability > exist in nv50_msto_atomic_disable() in the same file? [...] > If this is called during session teardown without a matching > .atomic_enable, couldn't msto->mstc be NULL, leading to a NULL > pointer dereference when accessing mstc->mstm? The shape is the same. nv50_msto_atomic_disable() takes msto->mstc without checking it (dispnv50/disp.c:1079-1080): struct nv50_mstc *mstc = msto->mstc; struct nv50_mstm *mstm = mstc->mstm; and the pointer can hold NULL: it is assigned only in nv50_msto_atomic_enable() (:1070) and set back to NULL in nv50_msto_cleanup() (:918). What I could not establish is that the callback is reached in that state. nv50 does not drive the encoder disable from the atomic helpers, it drives it from its own outp list in nv50_disp_atomic_commit_tail() (:2229 to :2240), and outp->clr.ctrl is only set in nv50_disp_outp_atomic_check_clr() (:2530), behind two conditions: the connector sat on a CRTC in the old state (:2517), and that CRTC was active in the old state (:2522). A CRTC that was active came up through a commit that ran .atomic_enable (:2272 to :2274), which is where msto->mstc is assigned. I did not find a way around that, so I cannot claim that a disable with no matching enable gets there. The one path I could not rule out is the early return in nv50_msto_atomic_enable(): if (WARN_ON(!mstc)) return; at :1049. It returns before the assignment at :1070, while commit_tail still sets outp->enabled = true at :2274. That sits behind a WARN_ON, so it is a second-order path rather than a fresh bug. For completeness, the other two places that read msto->mstc without a check, nv50_msto_cleanup() (:902 and :906 to :908) and nv50_msto_prepare() (:934), are covered by their callers, which test "mstc && mstc->mstm == mstm" at :1318, :1347 and :1359. nv50_real_outp() checks for itself at :889. The disable callback is the only reader left without a check. I am not adding a patch for it to this series, for the same reason 2/2 is scoped the way it is: 2/2 fixes something I hit on real hardware and can reproduce. This is MST, I have no MST setup here, and a guard written against a path I cannot exercise is a guess. If the maintainers want it anyway I will send it as a separate patch, but I would rather hear from someone who can run MST whether that callback is reachable with msto->mstc NULL at all. v4 stands as posted, no respin planned for this. The question is orthogonal to both patches.