On 4/4/24 14:38, Justin Stitt wrote:
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
Justin,
Yes, undo of that patch does fix the problem, the scsi controller and
all disks are visible.
So did changing .config so that FORTIFY would not be used.
Given other messages on this subject, there seems a basic conflict
between using strscpy() to mean -- copy however much will fit, and leave
a proper NUL-terminated string, versus FORTIFY trying to signal that
something has been lost. Is there a strscpy variation (_pad maybe?) that
FORTIFY will remain calm about truncation?
Charles Bertsch
