On Tue, May 20, 2025 at 07:35:40PM +0300, Baris Can Goral wrote:
> Hi,
> Rafael I dont understand your question. This patch replaces
> strncpy which is vulnerable with strscpy. As it stated in Link I shared.
Uses of strncpy are not inherently buggy, rather there is a corner case
where the string might happen to end up not terminated.
Rafael asked if that's what is being patched here.
> It seems it works to fix somethings.
If anything it seems to /break/ something.
In all reported cases the idle time went down significantly, which I
looks like an unexpected outcome.
So interestingly (to my reading anyway) this particular consumer
explicitly wants the target string to NOT be nul terminated.
The copied to struct is:
struct acpi_table_header {
[snip]
char oem_id[ACPI_OEM_ID_SIZE]; /* ASCII OEM identification */
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE]; /* ASCII OEM table identification */
[/snip]
};
Later the thing is NOT treated as a string, instead it is handled with
memcmp:
!memcmp(acpi_gbl_root_table_list.tables[i].pointer->
oem_table_id, header.oem_table_id,
ACPI_OEM_TABLE_ID_SIZE))) {
So, for "table ids" which occupy the entirety of ACPI_OEM_TABLE_ID_SIZE
(and which end up not null terminated), your patch changes the behavior
as they end up suddenly truncated by 1 to nul terminate, which then
makes them fail memcmp.
So the patch is not a nop and it breaks stuff afaics.
I thing the real bug here is that strscpy does anything of the sort.
Instead it should fail *and* be annotated with __must_check or whatever
the name it has on Linux so that consumers don't unknowingly introduce
truncated strings..
