[PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Kees Cook]

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?

(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
-- 
2.34.1

Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Rafael J. Wysocki]

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.

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

Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Kees Cook]

On Mon, Mar 23, 2026 at 06:31:20PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 23, 2026 at 6:24 PM Kees Cook <kees@kernel.org> wrote:
> > [...]
> > 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.

Okay, thanks! I wasn't sure if that was going to be a viable approach.
:)

-Kees

-- 
Kees Cook

Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Jiri Slaby]

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

Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Jiri Slaby]

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

Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()

[Jiri Slaby]

Ping?

On 29. 05. 26, 9:24, Jiri Slaby wrote:
> 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