On Thu, May 29, 2025 at 5:15 PM Ahmed Salem <x0rw3ll@xxxxxxxxx> wrote: > > 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@xxxxxxxxx/ [1] > Link: > https://github.com/acpica/acpica/pull/1024/commits/b90d0d65ec97ff8279ad826f4102e0d31c5f662a > [2] Sure. Thanks for the pointer. > > > > commit ebf27765421c9238b7835d32a95e4a7fb8db26a4 > > Author: Ahmed Salem <x0rw3ll@xxxxxxxxx> > > 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@xxxxxxxxx> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > Link: https://patch.msgid.link/1910878.atdPhlSkOF@xxxxxxxxxxxxx > [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. > > >
