All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.