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] [day] [month] [year] [list]
Message-ID: <CAJZ5v0iKQx+6U1LiRNpOQ05UCStda_rVBM+zo3Q74tozYYah+Q@mail.gmail.com>
Date: Thu, 29 May 2025 17:22:18 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ahmed Salem <x0rw3ll@...il.com>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>, 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

On Thu, May 29, 2025 at 5:15 PM Ahmed Salem <x0rw3ll@...il.com> 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@intel.com/ [1]
> Link:
> https://github.com/acpica/acpica/pull/1024/commits/b90d0d65ec97ff8279ad826f4102e0d31c5f662a
> [2]

Sure.  Thanks for the pointer.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ