From: Jiri Slaby <jirislaby@kernel.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>, Kees Cook <kees@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>,
Len Brown <lenb@kernel.org>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
acpica-devel@lists.linux.dev, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()
Date: Fri, 29 May 2026 09:24:55 +0200 [thread overview]
Message-ID: <79e9e913-0fb1-4110-804b-c3b5d0edafe4@kernel.org> (raw)
In-Reply-To: <405e97ae-72a1-4086-bef3-cf462619f661@kernel.org>
On 29. 05. 26, 9:20, Jiri Slaby wrote:
> On 23. 03. 26, 18:31, Rafael J. Wysocki wrote:
>> On Mon, Mar 23, 2026 at 6:24 PM Kees Cook <kees@kernel.org> wrote:
>>>
>>> Replace the deprecated[1] strncpy() with strscpy_pad() in
>>> acpi_ut_safe_strncpy().
>>>
>>> The function is a "safe strncpy" wrapper that does
>>> strncpy(dest, source, dest_size) followed by manual NUL-termination
>>> at dest[dest_size - 1]. strscpy_pad() is a direct replacement: it
>>> NUL-terminates, zero-pads the remainder, and the manual termination
>>> is no longer needed.
>>>
>>> All callers pass NUL-terminated source strings (C string literals,
>>> __FILE__ via ACPI_MODULE_NAME, or user-provided filenames that have
>>> already been validated). The destinations are fixed-size char arrays
>>> in ACPICA internal structures (allocation->module, aml_op_name,
>>> acpi_gbl_db_debug_filename), all consumed as C strings.
>>>
>>> No behavioral change: strscpy_pad() produces identical output to
>>> strncpy() + manual NUL-termination for NUL-terminated sources that
>>> are shorter than dest_size. For sources longer than dest_size,
>>> strncpy() wrote dest_size non-NUL bytes then the manual termination
>>> overwrote the last byte with NUL; strscpy_pad() writes dest_size-1
>>> bytes plus NUL: same result.
>>>
>>> Link: https://github.com/KSPP/linux/issues/90 [1]
>>> Signed-off-by: Kees Cook <kees@kernel.org>
>>> ---
>>> This touches the ACPICA component shared with the upstream ACPICA
>>> project (https://github.com/acpica/acpica), where the function
>>> is named AcpiUtSafeStrncpy(). The upstream codebase uses its own
>>> platform abstraction layer (acenv.h/acgcc.h) where I've mapped various
>>> kernel APIs before like ACPI_FLEX_ARRAY and similar helpers. However,
>>> acpi_ut_safe_strncpy() is an explicit function implementation rather
>>> than a macro mapping, so the approach for upstreaming this change to
>>> ACPICA is not clear. What's the best way to land this?
>>
>> I can apply this directly, it shouldn't be a major problem for porting
>> patches from the upstream.
>
> As I reported in https://github.com/acpica/acpica/issues/1158 (but got
> no reply), this patch breaks build of acpica against 7.1-rc*:
> > ../../../../../drivers/acpi/acpica/utnonansi.c:171:9: error: implicit
> declaration of function ‘strscpy_pad’ [-Wimplicit-function-declaration]
>
> Is strscpy_pad() supposed to be emulated in acpica?
No, I misread the log, it's the in-kernel acpidump failing to build:
~/linux/tools/power/acpi/tools/acpidump> make
MKDIR include
CP include
CC tools/acpidump/apdump.o
CC tools/acpidump/apfiles.o
CC tools/acpidump/apmain.o
CC tools/acpidump/osunixdir.o
CC tools/acpidump/osunixmap.o
CC tools/acpidump/osunixxf.o
CC tools/acpidump/tbprint.o
CC tools/acpidump/tbxfroot.o
CC tools/acpidump/utascii.o
CC tools/acpidump/utbuffer.o
CC tools/acpidump/utcksum.o
CC tools/acpidump/utdebug.o
CC tools/acpidump/utexcep.o
CC tools/acpidump/utglobal.o
CC tools/acpidump/uthex.o
CC tools/acpidump/utmath.o
CC tools/acpidump/utnonansi.o
../../../../../drivers/acpi/acpica/utnonansi.c: In function
‘acpi_ut_safe_strncpy’:
../../../../../drivers/acpi/acpica/utnonansi.c:171:9: error: implicit
declaration of function ‘strscpy_pad’ [-Wimplicit-function-declaration]
171 | strscpy_pad(dest, source, dest_size);
| ^~~~~~~~~~~
make: *** [../../Makefile.rules:25:
/home/xslaby/linux/tools/power/acpi/tools/acpidump/utnonansi.o] Chyba 1
>>> (This is one of the last users of strncpy in the kernel.)
>>> ---
>>> drivers/acpi/acpica/utnonansi.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/
>>> utnonansi.c
>>> index ff0802ace19b..3a7952be6545 100644
>>> --- a/drivers/acpi/acpica/utnonansi.c
>>> +++ b/drivers/acpi/acpica/utnonansi.c
>>> @@ -168,8 +168,7 @@ void acpi_ut_safe_strncpy(char *dest, char
>>> *source, acpi_size dest_size)
>>> {
>>> /* Always terminate destination string */
>>>
>>> - strncpy(dest, source, dest_size);
>>> - dest[dest_size - 1] = 0;
>>> + strscpy_pad(dest, source, dest_size);
>>> }
>>>
>>> #endif
>>> --
>>
>
> thanks,
--
js
suse labs
next prev parent reply other threads:[~2026-05-29 7:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 17:24 [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy() Kees Cook
2026-03-23 17:31 ` Rafael J. Wysocki
2026-03-24 8:01 ` Kees Cook
2026-05-29 7:20 ` Jiri Slaby
2026-05-29 7:24 ` Jiri Slaby [this message]
2026-06-04 6:32 ` Jiri Slaby
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=79e9e913-0fb1-4110-804b-c3b5d0edafe4@kernel.org \
--to=jirislaby@kernel.org \
--cc=acpica-devel@lists.linux.dev \
--cc=kees@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox