Hi,
On Mon, Apr 1, 2024 at 3:43 PM Charles Bertsch <cbertsch@xxxxxxx> wrote:
>
> I have hit a kernel BUG at lib/string_helpers.c:1046, apparently invoked
> from module mptsas.
>
> I use kernels compiled from source from kernel.org. I hit this when
> trying to step up to linux-6.7.11, after skipping some number of
> versions. Doing git bisect on the steps from 6.6.0 to 6.7.0, I ended with --
>
> 45e833f0e5bb1985721d4a52380db47c5dad2d49 is the first bad commit
> commit 45e833f0e5bb1985721d4a52380db47c5dad2d49
> Author: Justin Stitt <justinstitt@xxxxxxxxxx>
> Date: Tue Oct 3 22:15:45 2023 +0000
>
> scsi: message: fusion: Replace deprecated strncpy() with strscpy()
>
> strncpy() is deprecated for use on NUL-terminated destination
> strings [1]
> and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> The failure occurs during system startup, the six scsi disks are not
> found, apparently one of the udev tasks is near death holding an open
> file within the /dev directory.
>
> The apparently relevant part of the startup log is attached.
>
> The result of running lspci -v is also attached, as run by an
> unprivileged user, in which the relevant part may be --
>
> 04:00.0 SCSI storage controller: Broadcom / LSI SAS1064ET PCI-Express
> Fusion-MPT SAS (rev 04)
> Subsystem: Intel Corporation Device 3478
> Flags: bus master, fast devsel, latency 0, IRQ 17
> I/O ports at 4000 [size=256]
> Memory at b8910000 (64-bit, non-prefetchable) [size=16K]
> Memory at b8900000 (64-bit, non-prefetchable) [size=64K]
> Expansion ROM at <ignored> [disabled]
> Capabilities: <access denied>
> Kernel driver in use: mptsas
> Kernel modules: mptsas
>
> Only one of the systems I use for testing has this hardware, and has
> this problem.
>
> Trying to follow advice from Documentation/admin-guide/, I built a
> kernel with more recent (most recent?) code, identified as 6.9.0-rc2_64.
> The problem remains, with a similar start-up log, attached, but now
> with two "cut here" entries, buffer overflow at
> lib/string_helpers.c:1029, noted as "Not tainted", and invalid opcode at
> lib/string_helpers.c:1037, and now listed as "Tainted", presumably from
> the immediately earlier error.
>
> Please let me know what I can do to help.
Interestingly, after viewing the stack trace you provided, the last
line before a fortify panic is
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - -
mptsas_probe_one_phy.constprop.0.isra.0+0x7ff/0x850 [mptsas]
looking at this object file at that offset in gdb we see:
$ gdb $BUILD_DIR/drivers/message/fusion/mptsas.o
(gdb) list *(mptsas_probe_one_phy+0x7ff)
0x2f4f is in mptsas_exp_repmanufacture_info
(../drivers/message/fusion/mptsas.c:2984).
2979 edev->component_id = tmp[0] << 8 | tmp[1];
2980 edev->component_revision_id =
2981
manufacture_reply->component_revision_id;
2982 }
2983 } else {
2984 printk(MYIOC_s_ERR_FMT
2985 "%s: smp passthru reply failed to be
returned\n",
2986 ioc->name, __func__);
2987 ret = -ENXIO;
2988 }
with the offending line (+2984) being a printk invocation.
I am not sure how my patch [1] is triggering this fortify panic. I
didn't modify this printk or the string arguments (ioc->name), also
the change from strncpy to strscpy did not introduce any strnlen()'s
which seems to be the thing fortify is upset about:
"2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - detected buffer
overflow in strnlen"
or
"2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - strnlen: detected
buffer overflow: 9 byte read of buffer size 8"
Charles, does reverting my patch fix the problems you're seeing?
>
> Charles Bertsch
> 1-480-395-2620
> Phoenix AZ US
[1] https://lore.kernel.org/all/20231003-strncpy-drivers-message-fusion-mptsas-c-v2-1-5ce07e60bd21@xxxxxxxxxx/
Thanks
Justin
