Linux Hardening
 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: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


  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