[{"id":3685533,"web_url":"http://patchwork.ozlabs.org/comment/3685533/","msgid":"<20260504073407.A8A35C2BCB8@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-04T07:34:07","subject":"Re: [PATCH] char: agp: amd64 - fix null-ptr-deref in\n amd64_fetch_size and related functions","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n- [High] The patch masks a kernel crash symptom without fixing the underlying broken error propagation in `agp_amd64_probe()`, allowing the driver to erroneously proceed without hardware.\n- [Low] The newly added NULL pointer safeguards across multiple initialization and cleanup functions are mathematically redundant or structurally unreachable.\n--\n\ncommit 97080eec153aeef89c2ae80f04042c9b13cb0fb4\nAuthor: Mingyu Wang <25181214217@stu.xidian.edu.cn>\n\nchar: agp: amd64 - fix null-ptr-deref in amd64_fetch_size and related functions\n\nThis patch adds safeguards across the AMD64 AGP driver to verify that\nnode_to_amd_nb() and its misc pointer are not null. It attempts to fix a\nkernel panic in environments without a physical AMD Northbridge.\n\n> diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c\n> --- a/drivers/char/agp/amd64-agp.c\n> +++ b/drivers/char/agp/amd64-agp.c\n> @@ -121,14 +121,16 @@ static struct aper_size_info_32 amd64_aperture_sizes[7] =\n>  static int amd64_fetch_size(void)\n>  {\n>  \tstruct pci_dev *dev;\n> +\tstruct amd_northbridge *nb;\n>  \tint i;\n>  \tu32 temp;\n>  \tstruct aper_size_info_32 *values;\n>  \n> -\tdev = node_to_amd_nb(0)->misc;\n> -\tif (dev==NULL)\n> +\tnb = node_to_amd_nb(0);\n> +\tif (!nb || !nb->misc)\n>  \t\treturn 0;\n\nDoes returning 0 here merely mask the underlying issue?\n\nThe patch prevents a crash by handling the missing hardware here, but this\nstill allows the driver to erroneously proceed without hardware. Should\nagp_amd64_probe() be fixed to abort on cache_nbs() < 0 instead of just\nchecking for == -1, so the error propagates properly when hardware is\nmissing?\n\n[ ... ]\n\n> @@ -187,8 +189,12 @@ static int amd_8151_configure(void)\n>  \n>  \t/* Configure AGP regs in each x86-64 host bridge. */\n>  \tfor (i = 0; i < amd_nb_num(); i++) {\n> -\t\tagp_bridge->gart_bus_addr =\n> -\t\t\tamd64_configure(node_to_amd_nb(i)->misc, gatt_bus);\n> +\t\tstruct amd_northbridge *nb = node_to_amd_nb(i);\n> +\n> +\t\tif (!nb || !nb->misc)\n> +\t\t\tcontinue;\n\nAre these safeguards necessary inside the loop? \n\nSince the loop is bounded by amd_nb_num(), isn't the Northbridge descriptor\nand its misc pointer guaranteed to be non-NULL if amd_nb_num() is greater\nthan zero? This applies to amd_8151_configure(), amd64_cleanup(), and\ncache_nbs().\n\n[ ... ]\n\n> @@ -391,6 +409,7 @@ static int uli_agp_init(struct pci_dev *pdev)\n>  {\n>  \tu32 httfea,baseaddr,enuscr;\n>  \tstruct pci_dev *dev1;\n> +\tstruct amd_northbridge *nb;\n>  \tint i, ret;\n>  \tunsigned size = amd64_fetch_size();\n>  \n> @@ -411,9 +430,14 @@ static int uli_agp_init(struct pci_dev *pdev)\n>  \t\tgoto put;\n>  \t}\n>  \n> +\tnb = node_to_amd_nb(0);\n> +\tif (!nb || !nb->misc) {\n> +\t\tret = -ENODEV;\n> +\t\tgoto put;\n> +\t}\n\nIs this check structurally reachable?\n\nIf amd64_fetch_size() returned 0 earlier in this function due to missing\nhardware, the array lookup for uli_sizes will fail. This causes an early\n-ENODEV exit before ever reaching this new check. The same unreachable\nlogic appears to apply to the changes in nforce3_agp_init().","headers":{"Return-Path":"\n <linux-pci+bounces-53660-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=u4XmGl4I;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-53660-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"u4XmGl4I\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g8D101JHWz1yJ9\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 04 May 2026 17:34:12 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 9FAF23004926\n\tfor <incoming@patchwork.ozlabs.org>; Mon,  4 May 2026 07:34:08 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 47B182EAB82;\n\tMon,  4 May 2026 07:34:08 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 24E412E62A4\n\tfor <linux-pci@vger.kernel.org>; Mon,  4 May 2026 07:34:08 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id A8A35C2BCB8;\n\tMon,  4 May 2026 07:34:07 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777880048; cv=none;\n b=Ta8AbqRmK5gCIhktjNSyEfUf+KtP8oMtKlEYbvmm+HJyeE5Cpl8Cav9h4OsytMcZIn3rDUhm81TgfkXcredgvQy/LI+0IbBsAVNYLu1X2J99ZvMdngZDWyzsfmVzltivEb9rdM01ViUJRlefQxHjR90NgAH9V/+GVbGt0ethD6Y=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777880048; c=relaxed/simple;\n\tbh=nLpFKxxy96RsMsb4YVhVd7d+qnyjcU94pUM7BVaMUJA=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=IcSnQHyf4ic64S/WW0DFEFnOAXqlQArCDcutzvG8NMvlO1gbv8Otr7f48SlSaFusvppgZLOmACJUIZY6hMonwybTsx3j3+BhT6QF1kw26ULnXCpHOmOLqpI4CZlz0vgFfj+7cZd3cDRjnLpAhorbvNIWp5XtwOVaIZkN0dzsNI0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=u4XmGl4I; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777880047;\n\tbh=nLpFKxxy96RsMsb4YVhVd7d+qnyjcU94pUM7BVaMUJA=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=u4XmGl4IrIzjJnDqirYIMm0GY88K0SLMj2h2ToRZ+M/5KSyOaIyn4rOFAKSY4seBi\n\t kW8EuZARkVlKTNWOkPXgCJDpO0ALA0bqeEaEyturIT3I9cfehBHucbOQ4jsGWi+VQj\n\t lkpI4PCisAVvwNptIT37Acp8JbDSMVBprNF38KosUXygBsCNvH5tO9i+CMX7hikc+E\n\t CCu2fbjWR97DwkQ/ZPLJSZqKJHxoTvmJXbJlIpb2ZZRf7MzOcBXfMr9hje9yyktxhu\n\t +b8UGBeKi2g9e6OcxGEoIHtVWjQV0tUnwjvI9+1WDXfexr1soNH63cfM5KB3usWddb\n\t H3WPsCYEVyZXA==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH] char: agp: amd64 - fix null-ptr-deref in\n amd64_fetch_size and related functions","Reply-To":"sashiko@lists.linux.dev","To":"w15303746062@163.com","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260504065441.99033-1-w15303746062@163.com>","References":"<20260504065441.99033-1-w15303746062@163.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Mon, 04 May 2026 07:34:07 +0000","Message-Id":"<20260504073407.A8A35C2BCB8@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>"}}]