All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gary Guo" <gary@garyguo.net>
Cc: linux-scsi@vger.kernel.org, linux-pci@vger.kernel.org,
	cassel@kernel.org, dri-devel@lists.freedesktop.org,
	dlemoal@kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH v3 5/9] agp/via: don't rely on address of pci_device_id
Date: Tue, 07 Jul 2026 14:12:16 +0000	[thread overview]
Message-ID: <20260707141216.A81461F00A3F@smtp.kernel.org> (raw)
In-Reply-To: <20260706-pci_id_fix-v3-5-2d48fc025acc@garyguo.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] When a device binds via `driver_override`, the PCI core passes a generic `pci_device_id_any` struct with `driver_data` set to 0. Passing this NULL pointer to the `%s` format specifier results in an unhandled `(null)` log output.
--

commit cefd4bbcd02b1f8d8a6df6f9aa562b23cee64272
Author: Gary Guo <gary@garyguo.net>

agp/via: don't rely on address of pci_device_id
    
Address of pci_device_id cannot be relied on due to presence of dynamic ID
and driver_override. Use driver_data instead.

> diff --git a/drivers/char/agp/via-agp.c b/drivers/char/agp/via-agp.c
> index 8b19a5d1a09b4..ab3b73dd080af 100644
> --- a/drivers/char/agp/via-agp.c
> +++ b/drivers/char/agp/via-agp.c
[ ... ]
> @@ -437,17 +239,14 @@ static void check_via_agp3 (struct agp_bridge_data *bridge)
>  
>  static int agp_via_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  {
> -	struct agp_device_ids *devs = via_agp_device_ids;
>  	struct agp_bridge_data *bridge;
> -	int j = 0;
>  	u8 cap_ptr;
>  
>  	cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP);
>  	if (!cap_ptr)
>  		return -ENODEV;
>  
> -	j = ent - agp_via_pci_table;
> -	printk (KERN_INFO PFX "Detected VIA %s chipset\n", devs[j].chipset_name);
> +	dev_info(&pdev->dev, "Detected VIA %s chipset\n", (const char *)ent->driver_data);

[Severity: Low]
Could this result in printing a (null) value to the kernel log?

If an administrator forces binding of the driver to a device using the sysfs
driver_override feature, the PCI core passes a generic pci_device_id_any struct
with driver_data set to 0.

Passing this NULL pointer to the %s format specifier in dev_info() would
print (null) in the kernel logs instead of a valid string. Is it possible
to check ent->driver_data for NULL before attempting to print it, or fall back
to a default string?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706-pci_id_fix-v3-0-2d48fc025acc@garyguo.net?part=5

  reply	other threads:[~2026-07-07 14:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 14:11 [PATCH v3 0/9] pci: fix UAF and TOCTOU related to dynamic ID Gary Guo
2026-07-06 14:11 ` [PATCH v3 1/9] ata: don't store pci_device_id Gary Guo
2026-07-07  1:12   ` Damien Le Moal
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 2/9] nsp32: " Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 3/9] ipack: tpci200: " Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 4/9] mlxsw: " Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 5/9] agp/via: don't rely on address of pci_device_id Gary Guo
2026-07-07 14:12   ` sashiko-bot [this message]
2026-07-06 14:11 ` [PATCH v3 6/9] agp/amd-k7: " Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 7/9] pci: make pci_match_one_device match on ID instead of device Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 8/9] pci: fix dyn_id add TOCTOU Gary Guo
2026-07-07 14:12   ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 9/9] pci: fix UAF when probe runs concurrent to dyn ID removal Gary Guo
2026-07-07 14:12   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260707141216.A81461F00A3F@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.