Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH 3/4] PCI/sysfs: Handle a malformed _DSM result in acpi_attr_is_visible()
Date: Fri, 14 Aug 2026 07:19:46 +0000	[thread overview]
Message-ID: <20260814071951.085BD1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260814070522.2327975-4-kwilczynski@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The function `dsm_label_utf16s_to_utf8s` passes the byte length of an ACPI buffer as the `inlen` parameter to `utf16s_to_utf8s`, which expects the length in `wchar_t` elements, leading to an out-of-bounds read.
--

--- Patch [3]: [PATCH 3/4] PCI/sysfs: Handle a malformed _DSM result in acpi_attr_is_visible() ---
commit 1e24bdb9829d783f4fae2c39ec3d3567d6ea73df
Author: Krzysztof Wilczyński <kwilczynski@kernel.org>

PCI/sysfs: Handle a malformed _DSM result in acpi_attr_is_visible()

This commit updates acpi_attr_is_visible() to evaluate the Device Name
_DSM when deciding attribute visibility. This ensures each attribute is
only created when the exported element has a type that the read path
accepts, preventing failing reads for malformed objects.

Closes: https://github.com/pciutils/pciutils/issues/175

> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 5b08f50653a37..abb941530c560 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing how the _DSM
buffer is handled in this file, I noticed a pre-existing issue in
dsm_label_utf16s_to_utf8s():

drivers/pci/pci-label.c:dsm_label_utf16s_to_utf8s() {
	int len;

	len = utf16s_to_utf8s((const wchar_t *)obj->buffer.pointer,
			      obj->buffer.length,
			      UTF16_LITTLE_ENDIAN,
			      buf, PAGE_SIZE - 1);
	buf[len++] = '\n';

	return len;
}

Does this code pass a byte length instead of a character count?

Because utf16s_to_utf8s() expects the inlen parameter to represent the number
of 16-bit characters, passing obj->buffer.length (which is the size in bytes)
might instruct the function to process up to twice as many characters as are
actually allocated for the buffer.

Could this result in an out-of-bounds heap memory read when an unprivileged
user reads the world-readable /sys/bus/pci/devices/.../label sysfs file?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260814070522.2327975-1-kwilczynski@kernel.org?part=3

  reply	other threads:[~2026-08-14  7:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14  7:05 [PATCH 0/4] PCI/sysfs: Fix the ACPI device name attributes Krzysztof Wilczyński
2026-08-14  7:05 ` [PATCH 1/4] PCI/sysfs: Stop reporting _DSM failures as -EPERM Krzysztof Wilczyński
2026-08-14  7:19   ` sashiko-bot
2026-08-14  9:36     ` Krzysztof Wilczyński
2026-08-14  7:05 ` [PATCH 2/4] PCI/sysfs: Decouple acpi_index from the optional device name element Krzysztof Wilczyński
2026-08-14  7:11   ` sashiko-bot
2026-08-14  7:05 ` [PATCH 3/4] PCI/sysfs: Handle a malformed _DSM result in acpi_attr_is_visible() Krzysztof Wilczyński
2026-08-14  7:19   ` sashiko-bot [this message]
2026-08-14  9:35     ` Krzysztof Wilczyński
2026-08-14  7:05 ` [PATCH 4/4] PCI/sysfs: Pass the device name length in UTF-16 code units Krzysztof Wilczyński
2026-08-14  7:14   ` sashiko-bot
2026-08-14 10:22   ` Krzysztof Wilczyński
2026-08-14  9:45 ` [PATCH 0/4] PCI/sysfs: Fix the ACPI device name attributes Krzysztof Wilczyński

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=20260814071951.085BD1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-pci@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox