From: sashiko-bot@kernel.org
To: "Alex Elder" <elder@riscstar.com>
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v4 1/4] PCI: of: avoid allocations in of_pci_prop_compatible()
Date: Fri, 04 Sep 2026 13:59:54 +0000 [thread overview]
Message-ID: <20260904135954.696FA1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904134607.1856121-2-elder@riscstar.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The local variable `bufp` is incorrectly declared as `char` instead of `char *`. This truncates the stack array pointer `buf` to an 8-bit integer, leading to severe memory corruption and an immediate kernel panic during runtime.
- [Low] The local variable `i` is declared but never used after the patch.
--
commit 0153310b625600febac7ea5aec9fbd9871d0af03
Author: Alex Elder <elder@riscstar.com>
PCI: of: avoid allocations in of_pci_prop_compatible()
This patch replaces dynamic allocations for three compatible strings with a
single stack-allocated buffer. This avoids subsequent kernel crashes where
allocation failures would unconditionally trigger strlen() during device tree
properties initialization.
Link: https://lore.kernel.org/sashiko-reviews/a647bd56-7dc8-4fec-9d96-834622054cdf@riscstar.com
> diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c
> --- a/drivers/pci/of_property.c
> +++ b/drivers/pci/of_property.c
[ ... ]
> static int of_pci_prop_compatible(struct pci_dev *pdev,
> struct of_changeset *ocs,
> struct device_node *np)
> {
> const char *compat_strs[PROP_COMPAT_NUM] = { 0 };
> + char buf[PROP_COMPAT_NUM * PROP_SIZE] = { };
> + char bufp = buf;
[Severity: High]
Does this incorrectly declare bufp as a single char instead of a pointer?
Assigning the array address buf to an 8-bit char truncates the memory address.
> int i, ret;
[Severity: Low]
Is the variable i still needed here? The loop that used it to free the
allocated strings was removed by this patch, which will leave this as an
unused variable and cause a compiler warning.
> - compat_strs[PROP_COMPAT_PCI_VVVV_DDDD] =
> - kasprintf(GFP_KERNEL, "pci%x,%x", pdev->vendor, pdev->device);
> - compat_strs[PROP_COMPAT_PCICLASS_CCSSPP] =
> - kasprintf(GFP_KERNEL, "pciclass,%06x", pdev->class);
> - compat_strs[PROP_COMPAT_PCICLASS_CCSS] =
> - kasprintf(GFP_KERNEL, "pciclass,%04x", pdev->class >> 8);
> + ret = snprintf(bufp, PROP_SIZE, "pci%x,%x", pdev->vendor, pdev->device);
[Severity: High]
Will this snprintf call trigger a kernel panic upon dereference? Because bufp
is truncated to an 8-bit integer, passing it as the output buffer pointer to
snprintf() will result in an out-of-bounds memory access (unmapped low-memory
dereference) when evaluated during system boot or PCI device enumeration.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904134607.1856121-1-elder@riscstar.com?part=1
next prev parent reply other threads:[~2026-09-04 13:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 13:46 [PATCH v4 0/4] PCI: of: warn on bogus device_type property Alex Elder
2026-09-04 13:46 ` [PATCH v4 1/4] PCI: of: avoid allocations in of_pci_prop_compatible() Alex Elder
2026-09-04 13:59 ` sashiko-bot [this message]
2026-09-04 14:04 ` Alex Elder
2026-09-04 13:46 ` [PATCH v4 2/4] PCI: of: drop the reg_num argument to of_pci_set_address() Alex Elder
2026-09-04 14:03 ` sashiko-bot
2026-09-04 13:46 ` [PATCH v4 3/4] PCI: of: don't zero flags in of_pci_get_addr_flags() Alex Elder
2026-09-04 14:06 ` sashiko-bot
2026-09-04 13:46 ` [PATCH v4 4/4] PCI: of: introduce of_pci_verify_node() Alex Elder
2026-09-04 14:09 ` sashiko-bot
2026-09-08 10:40 ` kernel test robot
2026-09-08 14:15 ` kernel test robot
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=20260904135954.696FA1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=elder@riscstar.com \
--cc=linux-pci@vger.kernel.org \
--cc=robh@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.