Re: [PATCH] ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()
Jiri Slaby <[email protected]> Fri, 29 May 2026 09:20:53 +0200
| Newsgroups | dev.linux.lists.acpica-devel,org.kernel.vger.linux-acpi,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 23. 03. 26, 18:31, Rafael J. Wysocki wrote: > On Mon, Mar 23, 2026 at 6:24 PM Kees Cook <[email protected]> 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 <[email protected]> >> --- >> 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