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:20:53 +0200 [thread overview]
Message-ID: <405e97ae-72a1-4086-bef3-cf462619f661@kernel.org> (raw)
In-Reply-To: <CAJZ5v0hOS7j2f-wkmvarULCS-1+Zio2hOz2ExMvFXN61OPv_tQ@mail.gmail.com>
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?
>> (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:20 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 [this message]
2026-05-29 7:24 ` Jiri Slaby
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=405e97ae-72a1-4086-bef3-cf462619f661@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