linux-kernel - Re: 6.16-rc0/regression/bisected - commit ebf27765421c introduced a new warning KASAN: global-out-of-bounds in acpi_ut_safe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vkrdaqakxid6b4cmeknygxxstx2zerzuarryzwl66unce7jwe3@hbrlelzs4p7v>
Date: Thu, 29 May 2025 18:15:43 +0300
From: Ahmed Salem <x0rw3ll@...il.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc: rafael.j.wysocki@...el.com, linux-acpi@...r.kernel.org, 
	Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: 6.16-rc0/regression/bisected - commit ebf27765421c introduced a
 new warning KASAN: global-out-of-bounds in acpi_ut_safe_strncpy+0x1b

Hi Mike,

On 25/05/29 07:17PM, Mikhail Gavrilov wrote:
> Hi,
> 
> Yesterday, after booting fresh kernel feacb1774bd5,
> I spotted a new error message in the kernel log with the following stack trace:
> 
> [    3.032828] ==================================================================
> [    3.032832] BUG: KASAN: global-out-of-bounds in
> acpi_ut_safe_strncpy+0x1b/0x60
> [    3.032839] Read of size 16 at addr ffffffffa9d32760 by task swapper/0/1
> 
> [    3.032846] CPU: 16 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 6.15.0-feacb1774bd5+ #2 PREEMPT(lazy)
> [    3.032849] Hardware name: ASUS System Product Name/ROG STRIX
> B650E-I GAMING WIFI, BIOS 3222 03/05/2025
[snip]
> git blame says the first bad commit is ebf27765421c:

That is correct. This was a very shortsighted and uninformed commit on
my part, and we had this very same discussion on upstream ACPICA. Kernel
test robot also reported the same issue earlier[1].

The issue was that I mistakenly switched to `memcpy` in the
`acpi_ut_safe_strncpy` function in drivers/acpi/acpica/utnonansi.c, which
would have caused the buffer to be terminated one byte shorter than it
should really be. It's been rectified since, and should be pulled back
into mainline once it's cleared. I do apologize for the massive
inconvenience!

Rafael, is there a possibility this upstream commit[2] gets pulled into
mainline before the next cycle?

Link:
https://lore.kernel.org/oe-lkp/202505081033.50e45ff4-lkp@intel.com/ [1]
Link:
https://github.com/acpica/acpica/pull/1024/commits/b90d0d65ec97ff8279ad826f4102e0d31c5f662a
[2]

> 
> commit ebf27765421c9238b7835d32a95e4a7fb8db26a4
> Author: Ahmed Salem <x0rw3ll@...il.com>
> Date:   Fri Apr 25 21:32:12 2025 +0200
> 
>     ACPICA: Replace strncpy() with memcpy()
> 
>     ACPICA commit 83019b471e1902151e67c588014ba2d09fa099a3
> 
>     strncpy() is deprecated for NUL-terminated destination buffers[1].
> 
>     Use memcpy() for length-bounded destinations.
> 
>     Link: https://github.com/KSPP/linux/issues/90 [1]
>     Link: https://github.com/acpica/acpica/commit/83019b47
>     Signed-off-by: Ahmed Salem <x0rw3ll@...il.com>
>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>     Link: https://patch.msgid.link/1910878.atdPhlSkOF@rjwysocki.net
[snip]
>  drivers/acpi/acpica/utnonansi.c | 2 +-
> 
> And yes, I can confirm this catch.
> The kernel with ebf27765421c reverted no longer triggers this error message.
> 
> > sh /usr/src/kernels/6.16.0-0.rc0.250528gfeacb1774bd5.5.fc43.x86_64+debug/scripts/faddr2line /lib/debug/lib/modules/6.16.0-0.rc0.250528gfeacb1774bd5.5.fc43.x86_64+debug/vmlinux acpi_ut_safe_strncpy+0x1b
> acpi_ut_safe_strncpy+0x1b/0x60:
> acpi_ut_safe_strncpy at drivers/acpi/acpica/utnonansi.c:172
> 
> Ahmed, Let me know if you need further logs or help reproducing.

Thank you so much! No further action's needed on your part, and I
appreciate your effort, sincerely!

--
Best regards,
Ahmed Salem
> 
> Full hardware specs are here:
> https://linux-hardware.org/?probe=1244406425
> 
> I’m also attaching build config, full bisect logs, and kernel logs
> from each bisect step in archives.
> 
> -- 
> Best Regards,
> Mike Gavrilov.