From: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Narendra K <Narendra_K@dell.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH 4/4] PCI/sysfs: Pass the device name length in UTF-16 code units
Date: Fri, 14 Aug 2026 19:22:19 +0900 [thread overview]
Message-ID: <20260814101153.GA93086@rocinante> (raw)
In-Reply-To: <20260814070522.2327975-5-kwilczynski@kernel.org>
Hello Rafael,
> Currently, dsm_label_utf16s_to_utf8s() passes the ACPI buffer
> length to utf16s_to_utf8s() unchanged. The Device Name _DSM may
> return the device name as a buffer holding a UTF-16 string, and
> the ACPI length counts bytes while the converter counts wchar_t
> elements. The converter therefore receives a count twice the
> number of code units the buffer holds, and that count is its only
> bound on the input.
>
> A NUL code unit ends the conversion early, so a name that carries
> one is converted correctly and the error stays hidden. ACPICA
> zeroes the entire result allocation, and the padding placed after
> the buffer supplies that NUL for most lengths. Lengths that leave
> no padding, or a single byte of it, do not, and the conversion
> then runs up to its own length in bytes past the end of the
> allocation. The bytes beyond the allocation are decoded into the
> "label" attribute, which is world readable.
>
> Thus, divide the buffer length by the size of wchar_t so that the
> converter receives a count of code units. The division truncates,
> so the converter is never told to read more bytes than the buffer
> holds, including for an odd length.
>
> Reaching the out of bounds read needs firmware that returns the
> name as a buffer and omits the terminator.
[...]
> len = utf16s_to_utf8s((const wchar_t *)obj->buffer.pointer,
> - obj->buffer.length,
> + obj->buffer.length / sizeof(wchar_t),
> UTF16_LITTLE_ENDIAN,
> buf, PAGE_SIZE - 1);
While looking at this from PCI perspective, I also noticed something with
ACPI code base that we could also fix.
File drivers/acpi/device_sysfs.c, where the description_show() is adding
/sys/bus/acpi/devices/.../description sysfs attribute to each device where
this is supported/available using data from the ACPI _STR method, has the
following:
result = utf16s_to_utf8s(
(wchar_t *)str_obj->buffer.pointer,
str_obj->buffer.length,
UTF16_LITTLE_ENDIAN, buf,
PAGE_SIZE - 1);
I believe, the above code has potentially the same issue as the one PCI
has, and which we are fixing here. I can send a small patch to fix the
this, too, if you want.
Thank you!
Krzysztof
next prev parent reply other threads:[~2026-08-14 10:22 UTC|newest]
Thread overview: 15+ 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-09-25 22:02 ` Bjorn Helgaas
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
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 [this message]
2026-08-14 9:45 ` [PATCH 0/4] PCI/sysfs: Fix the ACPI device name attributes Krzysztof Wilczyński
2026-09-24 18:23 ` 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=20260814101153.GA93086@rocinante \
--to=kwilczynski@kernel.org \
--cc=Narendra_K@dell.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=rafael.j.wysocki@intel.com \
/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.