* startup BUG at lib/string_helpers.c from scsi fusion mptsas
@ 2024-04-01 22:43 Charles Bertsch
2024-04-03 23:20 ` Bart Van Assche
2024-04-04 21:38 ` Justin Stitt
0 siblings, 2 replies; 19+ messages in thread
From: Charles Bertsch @ 2024-04-01 22:43 UTC (permalink / raw)
To: justinstitt, linux-scsi, MPT-FusionLinux.pdl
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
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@google.com>
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.
Charles Bertsch
1-480-395-2620
Phoenix AZ US
[-- Attachment #2: Zinger_2024-04-01b_scsi_ctrl_startup_fail_mptsas.txt --]
[-- Type: text/plain, Size: 8234 bytes --]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - scsi host5: ioc0: LSISAS1064E B2, FwRev=011b0000h, Ports=1, MaxQ=483, IRQ=17
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - detected buffer overflow in strnlen
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ------------[ cut here ]------------
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - kernel BUG at lib/string_helpers.c:1046!
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - invalid opcode: 0000 [#1] PREEMPT SMP PTI
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - CPU: 1 PID: 67 Comm: udevd Not tainted 6.6.0-rc1_64+ #8
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Hardware name: Intel S5000PSL/S5000PSL, BIOS S5000.86B.10.40.0091.090520081447 09/05/2008
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RIP: 0010:fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Code: 7c c5 00 48 85 ff 75 de 41 bc ea ff ff ff 5b 44 89 e0 5d 41 5c 41 5d c3 0f 1f 00 48 89 fe 48 c7 c7 88 7a b9 81 e8 91 74 da ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 41 54 49 89 fc
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RSP: 0018:ffffc9000027f9f8 EFLAGS: 00010246
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RAX: 0000000000000023 RBX: ffff888103302800 RCX: c0000000ffffefff
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 0000000000004ffb RDI: 0000000000000001
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RBP: ffff888103692c00 R08: 0000000000000000 R09: 00000000ffffefff
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R10: ffffc9000027f8b0 R11: ffffffff81ebbd88 R12: ffff888102a39038
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R13: ffff88810322a000 R14: ffff888109322000 R15: ffff88810322a010
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - FS: 00007fe122f9d140(0000) GS:ffff888257c40000(0000) knlGS:0000000000000000
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - CR2: 00007fb101a87850 CR3: 0000000103f78000 CR4: 00000000000006e0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Call Trace:
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - <TASK>
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? die+0x2e/0x80
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? do_trap+0xd8/0x100
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? do_error_trap+0x65/0x80
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? exc_invalid_op+0x4b/0x60
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? asm_exc_invalid_op+0x16/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT - - - - last message buffered 1 times
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - mptsas_probe_one_phy.constprop.0.isra.0+0x7ff/0x850 [mptsas]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - mptsas_probe_hba_phys.isra.0+0x186/0x610 [mptsas]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - mptsas_scan_sas_topology+0x3b/0x2c0 [mptsas]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? __pm_runtime_idle+0x44/0x80
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - mptsas_probe+0x3bc/0x4d0 [mptsas]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - local_pci_probe+0x3c/0x90
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - pci_device_probe+0xac/0x160
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - really_probe+0xb4/0x2b0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - __driver_probe_device+0x6e/0x120
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - driver_probe_device+0x19/0xd0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - __driver_attach+0x7a/0x170
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? __device_attach_driver+0x100/0x100
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - bus_for_each_dev+0x6c/0xc0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - bus_add_driver+0xdf/0x1e0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - driver_register+0x53/0x100
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? 0xffffffffa009c000
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - mptsas_init+0x110/0x1000 [mptsas]
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - do_one_initcall+0x6a/0x2b0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? __kmem_cache_alloc_node+0x40/0x290
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? do_init_module+0x1e/0x200
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - do_init_module+0x5f/0x200
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - init_module_from_file+0x86/0xc0
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - idempotent_init_module+0x178/0x230
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - __x64_sys_finit_module+0x52/0x90
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - do_syscall_64+0x5e/0x90
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ? do_syscall_64+0x6b/0x90
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - entry_SYSCALL_64_after_hwframe+0x4b/0xb5
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RIP: 0033:0x7fe1234b0c09
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Code: 48 8d 3d 6a 1f 0d 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2f e2 0c 00 f7 d8 64 89 01 48
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RSP: 002b:00007ffc8c4df6b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RAX: ffffffffffffffda RBX: 000000000046db60 RCX: 00007fe1234b0c09
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00007fe12359da9d RDI: 000000000000000b
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000465260
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R10: 000000000000000b R11: 0000000000000246 R12: 00007fe12359da9d
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R13: 0000000000000000 R14: 0000000000456890 R15: 000000000046db60
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - </TASK>
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Modules linked in: sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 uas ata_generic pata_acpi coretemp ata_piix i2c_i801 libata i2c_smbus rng_core uhci_hcd rtc_cmos ehci_pci e1000e mptsas(+) mptscsih mptbase ehci_hcd ptp pps_core scsi_transport_sas i5k_amb
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - ---[ end trace 0000000000000000 ]---
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RIP: 0010:fortify_panic+0xf/0x20
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - Code: 7c c5 00 48 85 ff 75 de 41 bc ea ff ff ff 5b 44 89 e0 5d 41 5c 41 5d c3 0f 1f 00 48 89 fe 48 c7 c7 88 7a b9 81 e8 91 74 da ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 41 54 49 89 fc
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RSP: 0018:ffffc9000027f9f8 EFLAGS: 00010246
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RAX: 0000000000000023 RBX: ffff888103302800 RCX: c0000000ffffefff
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 0000000000004ffb RDI: 0000000000000001
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - RBP: ffff888103692c00 R08: 0000000000000000 R09: 00000000ffffefff
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R10: ffffc9000027f8b0 R11: ffffffff81ebbd88 R12: ffff888102a39038
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - R13: ffff88810322a000 R14: ffff888109322000 R15: ffff88810322a010
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - FS: 00007fe122f9d140(0000) GS:ffff888257c40000(0000) knlGS:0000000000000000
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2024-04-01T19:18:28.000000+00:00 zGMT kernel - - - CR2: 00007fb101a87850 CR3: 0000000103f78000 CR4: 00000000000006e0
2024-04-01T19:18:28.000000+00:00 zGMT udevd 65 - - worker [67] failed while handling '/devices/pci0000:00/0000:00:02.0/0000:01:00.0/0000:02:01.0/0000:04:00.0'
[-- Attachment #3: Note.scsi.mptsas.startup.failure.git-bisect --]
[-- Type: text/plain, Size: 1853 bytes --]
45e833f0e5bb1985721d4a52380db47c5dad2d49 is the first bad commit
commit 45e833f0e5bb1985721d4a52380db47c5dad2d49
Author: Justin Stitt <justinstitt@google.com>
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 only caller of mptsas_exp_repmanufacture_info() is
mptsas_probe_one_phy() which can allocate rphy in either
sas_end_device_alloc() or sas_expander_alloc(). Both of which
zero-allocate:
| rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
... this is supplied to mptsas_exp_repmanufacture_info() as edev meaning
that no future NUL-padding of edev members is needed.
Considering the above, a suitable replacement is strscpy() [2] due to the
fact that it guarantees NUL-termination on the destination buffer without
unnecessarily NUL-padding.
Also use the more idiomatic strscpy() pattern of (dest, src, sizeof(dest)).
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231003-strncpy-drivers-message-fusion-mptsas-c-v2-1-5ce07e60bd21@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/message/fusion/mptsas.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
[-- Attachment #4: Zinger_2024-04-01_mptsas_fail_lspci_v.txt --]
[-- Type: text/plain, Size: 13123 bytes --]
"PCI bus HW" -- "exec lspci -v 2>&1"
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: bus master, fast devsel, latency 0
Capabilities: <access denied>
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=01, subordinate=06, sec-latency=0
I/O behind bridge: 00003000-00004fff [size=8K]
Memory behind bridge: b8000000-b8afffff [size=11M]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=08, subordinate=08, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=09, subordinate=09, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev b1) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=0b, subordinate=0b, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: bus master, fast devsel, latency 0, IRQ 1
Memory at fe700000 (64-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
Kernel modules: i5k_amb
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
Kernel modules: i5k_amb
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
Kernel modules: i5k_amb
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
Subsystem: Intel Corporation Device 3478
Flags: fast devsel
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=0c, subordinate=0c, sec-latency=0
I/O behind bridge: 00002000-00002fff [size=4K]
Memory behind bridge: b8c00000-b8cfffff [size=1M]
Prefetchable memory behind bridge: 00000000b8e00000-00000000b8ffffff [size=2M]
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 23
I/O ports at 5080 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 22
I/O ports at 5060 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 23
I/O ports at 5040 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 22
I/O ports at 5020 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at b8d00400 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=32
I/O behind bridge: 00001000-00001fff [size=4K]
Memory behind bridge: b8b00000-b8bfffff [size=1M]
Prefetchable memory behind bridge: 00000000b0000000-00000000b7ffffff [size=128M]
Capabilities: <access denied>
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0
Kernel modules: intel_rng
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) (prog-if 8a [ISA Compatibility mode controller, supports both channels switched to PCI native mode, supports bus mastering])
Subsystem: Intel Corporation Device 3478
Flags: bus master, medium devsel, latency 0, IRQ 20
I/O ports at 01f0 [size=8]
I/O ports at 03f4
I/O ports at 0170 [size=8]
I/O ports at 0374
I/O ports at 50b0 [size=16]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, pata_acpi, ata_generic
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09) (prog-if 8f [PCI native mode controller, supports both channels switched to ISA compatibility mode, supports bus mastering])
Subsystem: Intel Corporation Device 3478
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
I/O ports at 50c8 [size=8]
I/O ports at 50e4 [size=4]
I/O ports at 50c0 [size=8]
I/O ports at 50e0 [size=4]
I/O ports at 50a0 [size=16]
Memory at b8d00000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ata_piix
Kernel modules: ata_piix, pata_acpi, ata_generic
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
Subsystem: Intel Corporation Device 3478
Flags: medium devsel, IRQ 20
I/O ports at 5000 [size=32]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
I/O behind bridge: 00003000-00004fff [size=8K]
Memory behind bridge: b8000000-b89fffff [size=10M]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=06, subordinate=06, sec-latency=64
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 17
Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00004000-00004fff [size=4K]
Memory behind bridge: b8900000-b89fffff [size=1M]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 18
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 00003000-00003fff [size=4K]
Memory behind bridge: b8000000-b88fffff [size=9M]
Prefetchable memory behind bridge: [disabled]
Capabilities: <access denied>
Kernel driver in use: pcieport
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
05:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corporation S5000PSLSATA Server Board
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at b8820000 (32-bit, non-prefetchable) [size=128K]
Memory at b8400000 (32-bit, non-prefetchable) [size=4M]
I/O ports at 3020 [size=32]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
05:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corporation S5000PSLSATA Server Board
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at b8800000 (32-bit, non-prefetchable) [size=128K]
Memory at b8000000 (32-bit, non-prefetchable) [size=4M]
I/O ports at 3000 [size=32]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
0c:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at b8c60000 (32-bit, non-prefetchable) [size=128K]
Memory at b8c40000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 2020 [size=32]
Expansion ROM at b8c80000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
0c:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at b8c20000 (32-bit, non-prefetchable) [size=128K]
Memory at b8c00000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 2000 [size=32]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
0d:0c.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ES1000 (rev 02) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 3478
Flags: bus master, stepping, fast Back2Back, medium devsel, latency 32, IRQ 11
Memory at b0000000 (32-bit, prefetchable) [size=128M]
I/O ports at 1000 [size=256]
Memory at b8b00000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
[-- Attachment #5: Zinger_2024-04-01c_scsi_ctrl_startup_fail_mptsas_6.9.0rc.txt --]
[-- Type: text/plain, Size: 15626 bytes --]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - scsi host5: ioc0: LSISAS1064E B2, FwRev=011b0000h, Ports=1, MaxQ=483, IRQ=17
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ------------[ cut here ]------------
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - strnlen: detected buffer overflow: 9 byte read of buffer size 8
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - WARNING: CPU: 1 PID: 79 at lib/string_helpers.c:1029 __fortify_report+0x3f/0x50
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Modules linked in: sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 uas ata_generic pata_acpi ata_piix coretemp uhci_hcd i2c_i801 libata i2c_smbus mptsas(+) ehci_pci mptscsih rng_core ehci_hcd e1000e ptp pps_core mptbase scsi_transport_sas rtc_cmos i5k_amb
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CPU: 1 PID: 79 Comm: udevd Not tainted 6.9.0-rc2_64 #9
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Hardware name: Intel S5000PSL/S5000PSL, BIOS S5000.86B.10.40.0091.090520081447 09/05/2008
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RIP: 0010:__fortify_report+0x3f/0x50
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Code: c1 83 e7 01 48 c7 c1 55 2e c6 81 48 c7 c7 c8 51 c3 81 48 8b 34 c5 40 9d a3 81 48 c7 c0 3a 2e c6 81 48 0f 45 c8 e8 c1 20 d0 ff <0f> 0b c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RSP: 0018:ffffc900002ff920 EFLAGS: 00010286
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RAX: 0000000000000000 RBX: ffff888107c82800 RCX: ffffffff81ea3aa8
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00000000ffffefff RDI: ffffffff81e4baa0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RBP: ffff88810034c600 R08: 0000000000000000 R09: ffffc900002ff7d0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R10: ffffc900002ff7c8 R11: ffffffff81ebbae8 R12: ffff888105a73038
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R13: ffff888105405000 R14: ffff88810082e000 R15: ffff888105405010
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - FS: 00007f0914580140(0000) GS:ffff888257c40000(0000) knlGS:0000000000000000
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CR2: 0000000000461c68 CR3: 00000001009be000 CR4: 00000000000006f0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Call Trace:
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - <TASK>
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __warn+0x68/0xd0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_report+0x3f/0x50
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? report_bug+0x185/0x190
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? handle_bug+0x42/0x70
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? exc_invalid_op+0x14/0x70
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? asm_exc_invalid_op+0x16/0x20
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_report+0x3f/0x50
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe_one_phy.constprop.0.isra.0+0x7f2/0x8f0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe_hba_phys.isra.0+0x186/0x610 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_scan_sas_topology+0x3b/0x2c0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pm_runtime_idle+0x44/0x80
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe+0x3c0/0x4e0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - local_pci_probe+0x41/0xa0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - pci_device_probe+0xac/0x170
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - really_probe+0xbc/0x2b0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __driver_probe_device+0x6e/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - driver_probe_device+0x19/0xe0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __driver_attach+0x81/0x180
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx___driver_attach+0x10/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - bus_for_each_dev+0x72/0xc0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - bus_add_driver+0xe3/0x1e0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - driver_register+0x57/0x110
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx_mptsas_init+0x10/0x10 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_init+0x110/0xff0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx_mptsas_init+0x10/0x10 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_one_initcall+0x6c/0x2d0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? kmalloc_trace+0x38/0x250
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_init_module+0x5f/0x210
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - init_module_from_file+0x86/0xd0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - idempotent_init_module+0x17c/0x230
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __x64_sys_finit_module+0x52/0x90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_syscall_64+0x7d/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? ksys_mmap_pgoff+0x83/0xd0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? syscall_exit_to_user_mode+0x7c/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_syscall_64+0x89/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? syscall_exit_to_user_mode+0x7c/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_syscall_64+0x89/0x120
2024-04-01T22:23:45.000000+00:00 zGMT - - - - last message buffered 2 times
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? irqentry_exit_to_user_mode+0x5d/0x100
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - entry_SYSCALL_64_after_hwframe+0x71/0x79
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RIP: 0033:0x7f0914a93c09
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Code: 48 8d 3d 6a 1f 0d 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2f e2 0c 00 f7 d8 64 89 01 48
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RSP: 002b:00007ffeaca080c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RAX: ffffffffffffffda RBX: 000000000046db60 RCX: 00007f0914a93c09
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00007f0914b80a9d RDI: 000000000000000b
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000465260
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R10: 000000000000000b R11: 0000000000000246 R12: 00007f0914b80a9d
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R13: 0000000000000000 R14: 0000000000464610 R15: 000000000046db60
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - </TASK>
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ---[ end trace 0000000000000000 ]---
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ------------[ cut here ]------------
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - kernel BUG at lib/string_helpers.c:1037!
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - invalid opcode: 0000 [#1] PREEMPT SMP PTI
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CPU: 1 PID: 79 Comm: udevd Tainted: G W 6.9.0-rc2_64 #9
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Hardware name: Intel S5000PSL/S5000PSL, BIOS S5000.86B.10.40.0091.090520081447 09/05/2008
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RIP: 0010:__fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Code: 0f 0b c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 40 0f b6 ff e8 97 ff ff ff <0f> 0b 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RSP: 0018:ffffc900002ff928 EFLAGS: 00010286
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RAX: 0000000000000000 RBX: ffff888107c82800 RCX: ffffffff81ea3aa8
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00000000ffffefff RDI: ffffffff81e4baa0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RBP: ffff88810034c600 R08: 0000000000000000 R09: ffffc900002ff7d0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R10: ffffc900002ff7c8 R11: ffffffff81ebbae8 R12: ffff888105a73038
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R13: ffff888105405000 R14: ffff88810082e000 R15: ffff888105405010
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - FS: 00007f0914580140(0000) GS:ffff888257c40000(0000) knlGS:0000000000000000
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CR2: 0000000000461c68 CR3: 00000001009be000 CR4: 00000000000006f0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Call Trace:
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - <TASK>
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? die+0x2e/0x80
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_trap+0xdb/0x100
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_error_trap+0x65/0x90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? exc_invalid_op+0x4b/0x70
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? asm_exc_invalid_op+0x16/0x20
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT - - - - last message buffered 1 times
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe_one_phy.constprop.0.isra.0+0x7f2/0x8f0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe_hba_phys.isra.0+0x186/0x610 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_scan_sas_topology+0x3b/0x2c0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pm_runtime_idle+0x44/0x80
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_probe+0x3c0/0x4e0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - local_pci_probe+0x41/0xa0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - pci_device_probe+0xac/0x170
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - really_probe+0xbc/0x2b0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __driver_probe_device+0x6e/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - driver_probe_device+0x19/0xe0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __driver_attach+0x81/0x180
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx___driver_attach+0x10/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - bus_for_each_dev+0x72/0xc0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - bus_add_driver+0xe3/0x1e0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - driver_register+0x57/0x110
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx_mptsas_init+0x10/0x10 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - mptsas_init+0x110/0xff0 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? __pfx_mptsas_init+0x10/0x10 [mptsas]
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_one_initcall+0x6c/0x2d0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? kmalloc_trace+0x38/0x250
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_init_module+0x5f/0x210
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - init_module_from_file+0x86/0xd0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - idempotent_init_module+0x17c/0x230
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - __x64_sys_finit_module+0x52/0x90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - do_syscall_64+0x7d/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? ksys_mmap_pgoff+0x83/0xd0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? syscall_exit_to_user_mode+0x7c/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_syscall_64+0x89/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? syscall_exit_to_user_mode+0x7c/0x120
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? do_syscall_64+0x89/0x120
2024-04-01T22:23:45.000000+00:00 zGMT - - - - last message buffered 2 times
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ? irqentry_exit_to_user_mode+0x5d/0x100
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - entry_SYSCALL_64_after_hwframe+0x71/0x79
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RIP: 0033:0x7f0914a93c09
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Code: 48 8d 3d 6a 1f 0d 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2f e2 0c 00 f7 d8 64 89 01 48
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RSP: 002b:00007ffeaca080c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RAX: ffffffffffffffda RBX: 000000000046db60 RCX: 00007f0914a93c09
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00007f0914b80a9d RDI: 000000000000000b
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000465260
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R10: 000000000000000b R11: 0000000000000246 R12: 00007f0914b80a9d
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R13: 0000000000000000 R14: 0000000000464610 R15: 000000000046db60
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - </TASK>
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Modules linked in: sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 uas ata_generic pata_acpi ata_piix coretemp uhci_hcd i2c_i801 libata i2c_smbus mptsas(+) ehci_pci mptscsih rng_core ehci_hcd e1000e ptp pps_core mptbase scsi_transport_sas rtc_cmos i5k_amb
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - ---[ end trace 0000000000000000 ]---
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RIP: 0010:__fortify_panic+0x9/0x10
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - Code: 0f 0b c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 40 0f b6 ff e8 97 ff ff ff <0f> 0b 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RSP: 0018:ffffc900002ff928 EFLAGS: 00010286
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RAX: 0000000000000000 RBX: ffff888107c82800 RCX: ffffffff81ea3aa8
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RDX: 0000000000000000 RSI: 00000000ffffefff RDI: ffffffff81e4baa0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - RBP: ffff88810034c600 R08: 0000000000000000 R09: ffffc900002ff7d0
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R10: ffffc900002ff7c8 R11: ffffffff81ebbae8 R12: ffff888105a73038
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - R13: ffff888105405000 R14: ffff88810082e000 R15: ffff888105405010
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - FS: 00007f0914580140(0000) GS:ffff888257c40000(0000) knlGS:0000000000000000
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2024-04-01T22:23:45.000000+00:00 zGMT kernel - - - CR2: 0000000000461c68 CR3: 00000001009be000 CR4: 00000000000006f0
2024-04-01T22:23:45.000000+00:00 zGMT udevd 67 - - worker [79] failed while handling '/devices/pci0000:00/0000:00:02.0/0000:01:00.0/0000:02:01.0/0000:04:00.0'
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-01 22:43 startup BUG at lib/string_helpers.c from scsi fusion mptsas Charles Bertsch
@ 2024-04-03 23:20 ` Bart Van Assche
2024-04-04 19:58 ` Justin Stitt
2024-04-04 21:38 ` Justin Stitt
1 sibling, 1 reply; 19+ messages in thread
From: Bart Van Assche @ 2024-04-03 23:20 UTC (permalink / raw)
To: Charles Bertsch, justinstitt, linux-scsi, MPT-FusionLinux.pdl
On 4/1/24 3:43 PM, Charles Bertsch wrote:
> 45e833f0e5bb1985721d4a52380db47c5dad2d49 is the first bad commit
> commit 45e833f0e5bb1985721d4a52380db47c5dad2d49
> Author: Justin Stitt <justinstitt@google.com>
> 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.
Justin, can you please take a look at this email and its attachments?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-03 23:20 ` Bart Van Assche
@ 2024-04-04 19:58 ` Justin Stitt
0 siblings, 0 replies; 19+ messages in thread
From: Justin Stitt @ 2024-04-04 19:58 UTC (permalink / raw)
To: Bart Van Assche; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Wed, Apr 3, 2024 at 4:20 PM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 4/1/24 3:43 PM, Charles Bertsch wrote:
> > 45e833f0e5bb1985721d4a52380db47c5dad2d49 is the first bad commit
> > commit 45e833f0e5bb1985721d4a52380db47c5dad2d49
> > Author: Justin Stitt <justinstitt@google.com>
> > 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.
> Justin, can you please take a look at this email and its attachments?
>
Looking now. I must've broken something!
> Thanks,
>
> Bart.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-01 22:43 startup BUG at lib/string_helpers.c from scsi fusion mptsas Charles Bertsch
2024-04-03 23:20 ` Bart Van Assche
@ 2024-04-04 21:38 ` Justin Stitt
2024-04-04 21:53 ` James Bottomley
2024-04-06 20:42 ` Charles Bertsch
1 sibling, 2 replies; 19+ messages in thread
From: Justin Stitt @ 2024-04-04 21:38 UTC (permalink / raw)
To: Charles Bertsch; +Cc: linux-scsi, MPT-FusionLinux.pdl
Hi,
On Mon, Apr 1, 2024 at 3:43 PM Charles Bertsch <cbertsch@cox.net> 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@google.com>
> 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@google.com/
Thanks
Justin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 21:38 ` Justin Stitt
@ 2024-04-04 21:53 ` James Bottomley
2024-04-04 22:04 ` Justin Stitt
2024-04-06 20:42 ` Charles Bertsch
1 sibling, 1 reply; 19+ messages in thread
From: James Bottomley @ 2024-04-04 21:53 UTC (permalink / raw)
To: Justin Stitt, Charles Bertsch; +Cc: linux-scsi, MPT-FusionLinux.pdl
On Thu, 2024-04-04 at 14:38 -0700, Justin Stitt wrote:
[...]
> 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"
it's sitting in the definition of sized_strscpy in fortify-string.h
Since the fields in question aren't zero terminated there's a bad
assumption that you can do strnlen on the source field.
James
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 21:53 ` James Bottomley
@ 2024-04-04 22:04 ` Justin Stitt
2024-04-04 22:29 ` James Bottomley
0 siblings, 1 reply; 19+ messages in thread
From: Justin Stitt @ 2024-04-04 22:04 UTC (permalink / raw)
To: James Bottomley; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
Hi,
On Thu, Apr 4, 2024 at 2:53 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Thu, 2024-04-04 at 14:38 -0700, Justin Stitt wrote:
> [...]
> > 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"
>
> it's sitting in the definition of sized_strscpy in fortify-string.h
I see now, I was jumping to the definition in lib/...
>
> Since the fields in question aren't zero terminated there's a bad
> assumption that you can do strnlen on the source field.
It's interesting that fortify doesn't like if the len argument is one
byte larger than the source argument because while technically it does
overread the buffer strscpy will manually write a NUL-byte to the
destination buffer.
The easy fix I see that doesn't limit the amount of representable data
is to increase these fields by 1 to match sas_expander_device.
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 300f8e955a53..44b492698e06 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -2833,10 +2833,10 @@ struct rep_manu_reply{
u8 sas_format:1;
u8 reserved1:7;
u8 reserved2[3];
- u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
- u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN];
- u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN];
- u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN];
+ u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
+ u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN+1];
+ u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN+1];
+ u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN+1];
u16 component_id;
u8 component_revision_id;
u8 reserved3;
which matches:
struct sas_expander_device {
...
#define SAS_EXPANDER_VENDOR_ID_LEN 8
char vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
#define SAS_EXPANDER_PRODUCT_ID_LEN 16
char product_id[SAS_EXPANDER_PRODUCT_ID_LEN+1];
#define SAS_EXPANDER_PRODUCT_REV_LEN 4
char product_rev[SAS_EXPANDER_PRODUCT_REV_LEN+1];
#define SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN 8
char component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN+1];
...
If this is A-OK, I'll send a patch.
>
> James
>
Thanks
Justin
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:04 ` Justin Stitt
@ 2024-04-04 22:29 ` James Bottomley
2024-04-04 22:33 ` James Bottomley
0 siblings, 1 reply; 19+ messages in thread
From: James Bottomley @ 2024-04-04 22:29 UTC (permalink / raw)
To: Justin Stitt; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Thu, 2024-04-04 at 15:04 -0700, Justin Stitt wrote:
> Hi,
>
> On Thu, Apr 4, 2024 at 2:53 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Thu, 2024-04-04 at 14:38 -0700, Justin Stitt wrote:
> > [...]
> > > 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"
> >
> > it's sitting in the definition of sized_strscpy in fortify-string.h
>
> I see now, I was jumping to the definition in lib/...
>
> >
> > Since the fields in question aren't zero terminated there's a bad
> > assumption that you can do strnlen on the source field.
>
> It's interesting that fortify doesn't like if the len argument is one
> byte larger than the source argument because while technically it
> does
> overread the buffer strscpy will manually write a NUL-byte to the
> destination buffer.
>
> The easy fix I see that doesn't limit the amount of representable
> data
> is to increase these fields by 1 to match sas_expander_device.
>
> diff --git a/drivers/message/fusion/mptsas.c
> b/drivers/message/fusion/mptsas.c
> index 300f8e955a53..44b492698e06 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2833,10 +2833,10 @@ struct rep_manu_reply{
> u8 sas_format:1;
> u8 reserved1:7;
> u8 reserved2[3];
> - u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
> - u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN];
> - u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN];
> - u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN];
> + u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
> + u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN+1];
> + u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN+1];
> + u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN+1];
This is a reply returned by the firmware ... we can't just arbitrarily
change field sizes because then it won't match what the firmware is
sending.
James
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:29 ` James Bottomley
@ 2024-04-04 22:33 ` James Bottomley
2024-04-04 22:43 ` Martin K. Petersen
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: James Bottomley @ 2024-04-04 22:33 UTC (permalink / raw)
To: Justin Stitt; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Thu, 2024-04-04 at 18:29 -0400, James Bottomley wrote:
> On Thu, 2024-04-04 at 15:04 -0700, Justin Stitt wrote:
[...]
> > It's interesting that fortify doesn't like if the len argument is
> > one byte larger than the source argument because while technically
> > it does overread the buffer strscpy will manually write a NUL-byte
> > to the destination buffer.
> >
> > The easy fix I see that doesn't limit the amount of representable
> > data is to increase these fields by 1 to match sas_expander_device.
> >
> > diff --git a/drivers/message/fusion/mptsas.c
> > b/drivers/message/fusion/mptsas.c
> > index 300f8e955a53..44b492698e06 100644
> > --- a/drivers/message/fusion/mptsas.c
> > +++ b/drivers/message/fusion/mptsas.c
> > @@ -2833,10 +2833,10 @@ struct rep_manu_reply{
> > u8 sas_format:1;
> > u8 reserved1:7;
> > u8 reserved2[3];
> > - u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
> > - u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN];
> > - u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN];
> > - u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN];
> > + u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
> > + u8 product_id[SAS_EXPANDER_PRODUCT_ID_LEN+1];
> > + u8 product_rev[SAS_EXPANDER_PRODUCT_REV_LEN+1];
> > + u8 component_vendor_id[SAS_EXPANDER_COMPONENT_VENDOR_ID_LEN+1];
>
> This is a reply returned by the firmware ... we can't just
> arbitrarily change field sizes because then it won't match what the
> firmware is sending.
But additionally this is a common pattern in SCSI: using strncpy to
zero terminate fields that may be unterminated in the exchange protocol
so we can send them to sysfs or otherwise treat them as strings. That
means we might have this problem in other drivers you've converted ...
James
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:33 ` James Bottomley
@ 2024-04-04 22:43 ` Martin K. Petersen
2024-04-04 22:47 ` Justin Stitt
2024-04-04 23:57 ` Kees Cook
2 siblings, 0 replies; 19+ messages in thread
From: Martin K. Petersen @ 2024-04-04 22:43 UTC (permalink / raw)
To: James Bottomley
Cc: Justin Stitt, Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
James,
> But additionally this is a common pattern in SCSI: using strncpy to
> zero terminate fields that may be unterminated in the exchange
> protocol so we can send them to sysfs or otherwise treat them as
> strings.
Yep, it's such a common pattern. I frankly don't know why our string
handling deals so poorly with fixed-length strings.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:33 ` James Bottomley
2024-04-04 22:43 ` Martin K. Petersen
@ 2024-04-04 22:47 ` Justin Stitt
2024-04-04 23:39 ` Kees Cook
2024-04-04 23:57 ` Kees Cook
2 siblings, 1 reply; 19+ messages in thread
From: Justin Stitt @ 2024-04-04 22:47 UTC (permalink / raw)
To: James Bottomley
Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl, Kees Cook
Cc'ing Kees.
On Thu, Apr 4, 2024 at 3:33 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> But additionally this is a common pattern in SCSI: using strncpy to
> zero terminate fields that may be unterminated in the exchange protocol
> so we can send them to sysfs or otherwise treat them as strings. That
> means we might have this problem in other drivers you've converted ...
Correct. Although certain conditions must be met:
1) length argument is larger than source but less than or equal to destination
2) source is not NUL-terminated
3) sizes known at compile-time
I think fortified strscpy needs to be a bit more lenient towards
source buffer overreads when we know strscpy should just truncate and
NUL-terminate.
Kees, what do you think?
>
> James
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:47 ` Justin Stitt
@ 2024-04-04 23:39 ` Kees Cook
2024-04-05 0:10 ` Justin Stitt
0 siblings, 1 reply; 19+ messages in thread
From: Kees Cook @ 2024-04-04 23:39 UTC (permalink / raw)
To: Justin Stitt
Cc: James Bottomley, Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Thu, Apr 04, 2024 at 03:47:05PM -0700, Justin Stitt wrote:
> Cc'ing Kees.
>
> On Thu, Apr 4, 2024 at 3:33 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > But additionally this is a common pattern in SCSI: using strncpy to
> > zero terminate fields that may be unterminated in the exchange protocol
> > so we can send them to sysfs or otherwise treat them as strings. That
> > means we might have this problem in other drivers you've converted ...
That's why we've been doing these one at a time and getting maintainers
to review them. :) Justin (and the reviewers) have been trying to be
careful with these, and documenting the rationales, etc, but this is
kind of why we're doing the conversion: using strncpy is really
ambiguous as far as showing what an author intended to be happening.
> Correct. Although certain conditions must be met:
>
> 1) length argument is larger than source but less than or equal to destination
> 2) source is not NUL-terminated
> 3) sizes known at compile-time
>
> I think fortified strscpy needs to be a bit more lenient towards
> source buffer overreads when we know strscpy should just truncate and
> NUL-terminate.
Okay, so the problem here is that the _source_ fields aren't NUL
terminated?
struct sas_expander_device {
...
#define SAS_EXPANDER_VENDOR_ID_LEN 8
char vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
...
};
struct rep_manu_reply {
...
u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
...
};
Okay, so struct rep_manu_reply needs __nonstring markings, and the
strscpy()s need to be memcpy()s.
We've done those kinds of conversions in the past; it just looks like we
made an analysis mistake here. Sorry about that!
-Kees
--
Kees Cook
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 22:33 ` James Bottomley
2024-04-04 22:43 ` Martin K. Petersen
2024-04-04 22:47 ` Justin Stitt
@ 2024-04-04 23:57 ` Kees Cook
2 siblings, 0 replies; 19+ messages in thread
From: Kees Cook @ 2024-04-04 23:57 UTC (permalink / raw)
To: James Bottomley
Cc: Justin Stitt, Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Thu, Apr 04, 2024 at 06:33:38PM -0400, James Bottomley wrote:
> But additionally this is a common pattern in SCSI: using strncpy to
> zero terminate fields that may be unterminated in the exchange protocol
> so we can send them to sysfs or otherwise treat them as strings. That
> means we might have this problem in other drivers you've converted ...
This use of copying a maybe-NUL-terminated source is yet another weird
corner-case of strncpy(). :(
But it's also easy to check for this "strncpy used with size
matching source size but destination is bigger" case with some build
instrumentation. I'll see what it turns up.
--
Kees Cook
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 23:39 ` Kees Cook
@ 2024-04-05 0:10 ` Justin Stitt
2024-04-05 0:12 ` Justin Stitt
0 siblings, 1 reply; 19+ messages in thread
From: Justin Stitt @ 2024-04-05 0:10 UTC (permalink / raw)
To: Kees Cook
Cc: James Bottomley, Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Thu, Apr 4, 2024 at 4:39 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Apr 04, 2024 at 03:47:05PM -0700, Justin Stitt wrote:
> > Cc'ing Kees.
> >
> > On Thu, Apr 4, 2024 at 3:33 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > But additionally this is a common pattern in SCSI: using strncpy to
> > > zero terminate fields that may be unterminated in the exchange protocol
> > > so we can send them to sysfs or otherwise treat them as strings. That
> > > means we might have this problem in other drivers you've converted ...
>
> That's why we've been doing these one at a time and getting maintainers
> to review them. :) Justin (and the reviewers) have been trying to be
> careful with these, and documenting the rationales, etc, but this is
> kind of why we're doing the conversion: using strncpy is really
> ambiguous as far as showing what an author intended to be happening.
>
> > Correct. Although certain conditions must be met:
> >
> > 1) length argument is larger than source but less than or equal to destination
> > 2) source is not NUL-terminated
> > 3) sizes known at compile-time
> >
> > I think fortified strscpy needs to be a bit more lenient towards
> > source buffer overreads when we know strscpy should just truncate and
> > NUL-terminate.
>
> Okay, so the problem here is that the _source_ fields aren't NUL
> terminated?
>
> struct sas_expander_device {
> ...
> #define SAS_EXPANDER_VENDOR_ID_LEN 8
> char vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
> ...
> };
>
> struct rep_manu_reply {
> ...
> u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
> ...
> };
>
> Okay, so struct rep_manu_reply needs __nonstring markings, and the
> strscpy()s need to be memcpy()s.
>
rep_manu_reply->xyz is the source, sure we can mark those as
__nonstring but don't we want the source to be potentially
NUL-terminated (says James). Are you suggesting a memcpy() followed by
a manual NUL-byte assignment?
> We've done those kinds of conversions in the past; it just looks like we
> made an analysis mistake here. Sorry about that!
>
> -Kees
>
> --
> Kees Cook
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-05 0:10 ` Justin Stitt
@ 2024-04-05 0:12 ` Justin Stitt
0 siblings, 0 replies; 19+ messages in thread
From: Justin Stitt @ 2024-04-05 0:12 UTC (permalink / raw)
To: Kees Cook
Cc: James Bottomley, Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
Agh, typo.
On Thu, Apr 4, 2024 at 5:10 PM Justin Stitt <justinstitt@google.com> wrote:
>
> On Thu, Apr 4, 2024 at 4:39 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Thu, Apr 04, 2024 at 03:47:05PM -0700, Justin Stitt wrote:
> > > Cc'ing Kees.
> > >
> > > On Thu, Apr 4, 2024 at 3:33 PM James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > But additionally this is a common pattern in SCSI: using strncpy to
> > > > zero terminate fields that may be unterminated in the exchange protocol
> > > > so we can send them to sysfs or otherwise treat them as strings. That
> > > > means we might have this problem in other drivers you've converted ...
> >
> > That's why we've been doing these one at a time and getting maintainers
> > to review them. :) Justin (and the reviewers) have been trying to be
> > careful with these, and documenting the rationales, etc, but this is
> > kind of why we're doing the conversion: using strncpy is really
> > ambiguous as far as showing what an author intended to be happening.
> >
> > > Correct. Although certain conditions must be met:
> > >
> > > 1) length argument is larger than source but less than or equal to destination
> > > 2) source is not NUL-terminated
> > > 3) sizes known at compile-time
> > >
> > > I think fortified strscpy needs to be a bit more lenient towards
> > > source buffer overreads when we know strscpy should just truncate and
> > > NUL-terminate.
> >
> > Okay, so the problem here is that the _source_ fields aren't NUL
> > terminated?
> >
> > struct sas_expander_device {
> > ...
> > #define SAS_EXPANDER_VENDOR_ID_LEN 8
> > char vendor_id[SAS_EXPANDER_VENDOR_ID_LEN+1];
> > ...
> > };
> >
> > struct rep_manu_reply {
> > ...
> > u8 vendor_id[SAS_EXPANDER_VENDOR_ID_LEN];
> > ...
> > };
> >
> > Okay, so struct rep_manu_reply needs __nonstring markings, and the
> > strscpy()s need to be memcpy()s.
> >
>
> rep_manu_reply->xyz is the source, sure we can mark those as
> __nonstring but don't we want the source to be potentially
> NUL-terminated (says James). Are you suggesting a memcpy() followed by
> a manual NUL-byte assignment?
... don't we want the DESTINATION to be ...
>
> > We've done those kinds of conversions in the past; it just looks like we
> > made an analysis mistake here. Sorry about that!
> >
> > -Kees
> >
> > --
> > Kees Cook
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-04 21:38 ` Justin Stitt
2024-04-04 21:53 ` James Bottomley
@ 2024-04-06 20:42 ` Charles Bertsch
2024-04-08 19:59 ` Justin Stitt
1 sibling, 1 reply; 19+ messages in thread
From: Charles Bertsch @ 2024-04-06 20:42 UTC (permalink / raw)
To: Justin Stitt; +Cc: linux-scsi, MPT-FusionLinux.pdl
On 4/4/24 14:38, Justin Stitt wrote:
> Hi,
>
> On Mon, Apr 1, 2024 at 3:43 PM Charles Bertsch <cbertsch@cox.net> 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@google.com>
>> 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@google.com/
>
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-06 20:42 ` Charles Bertsch
@ 2024-04-08 19:59 ` Justin Stitt
2024-04-08 23:19 ` Kees Cook
0 siblings, 1 reply; 19+ messages in thread
From: Justin Stitt @ 2024-04-08 19:59 UTC (permalink / raw)
To: Charles Bertsch, Kees Cook; +Cc: linux-scsi, MPT-FusionLinux.pdl
https://lore.kernel.org/all/d45631ac-3ee6-45cc-8b5a-fab130ce39d7@cox.net/
On Sat, Apr 6, 2024 at 1:42 PM Charles Bertsch <cbertsch@cox.net> wrote:
> 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?
I think fortified strscpy() should allow for the truncation, this, at
least in my eyes, is the expected behavior of strscpy(). You copy as
much as you can from the source and slap a '\0' to the end without
overflowing the destination.
I think Kees has some plans to address this as we spoke offline.
>
> Charles Bertsch
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-08 19:59 ` Justin Stitt
@ 2024-04-08 23:19 ` Kees Cook
2024-04-10 20:51 ` Justin Stitt
0 siblings, 1 reply; 19+ messages in thread
From: Kees Cook @ 2024-04-08 23:19 UTC (permalink / raw)
To: Justin Stitt; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
On Mon, Apr 08, 2024 at 12:59:52PM -0700, Justin Stitt wrote:
> https://lore.kernel.org/all/d45631ac-3ee6-45cc-8b5a-fab130ce39d7@cox.net/
>
> On Sat, Apr 6, 2024 at 1:42 PM Charles Bertsch <cbertsch@cox.net> wrote:
> > 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?
>
> I think fortified strscpy() should allow for the truncation, this, at
> least in my eyes, is the expected behavior of strscpy(). You copy as
> much as you can from the source and slap a '\0' to the end without
> overflowing the destination.
The trouble is with truncation. Some strings:
char longstr[] = "This is long."; // sizeof(longstr) == 14, strlen(longstr) == 13
char truncstr[] = "This is trunc";
char nonstr[sizeof(truncstr) - 1]; // sizeof(nonstr) == 13
char dest[64];
/* Create "nonstr" without a trailing NUL */
memcpy(nonstr, trunc, strlen(trunc));
strscpy(dest, long, sizeof(dest) /* 64 */)
=> 13 (i.e. strlen(longstr))
strscpy(dest, long, strlen(longstr) + 1 /* 14 */)
=> 13
strscpy(dest, long, strlen(longstr) /* 13 */)
=> -E2BIG, we saw that "." wasn't a NUL
strscpy(dest, nonstr, 13)
=> -E2BIG, we saw that "." wasn't a NUL
strscpy(dest, nonstr, 14)
=> fortify error, we can't examine the char after "."
If we used sizeof(src) to try to work around the off-by-one, we'd
suddenly lose the ability to detect actually corrupt strings, because
we'd silently start "accepting" strings that were exactly sized off by
1, and gain ambiguity in our handling.
> I think Kees has some plans to address this as we spoke offline.
But, this use of strncpy() *is* another "legitimate" use-case. But like
the other strncpy() uses, it is ambiguous. So, I think we need the
reverse of strtomem(), to take a "maybe NUL padded but not terminated"
character array and unambiguously construct a NUL-terminated string from
it.
I think something like this, memtostr:
diff --git a/include/linux/string.h b/include/linux/string.h
index 9ba8b4597009..5def02c7c0ce 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -422,6 +422,30 @@ void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
memcpy(dest, src, strnlen(src, min(_src_len, _dest_len))); \
} while (0)
+/**
+ * memtostr - Copy a possibly non-NUL-term string to a NUL-term string
+ * @dest: Pointer to destination NUL-terminates string
+ * @src: Pointer to character array (likely marked as __nonstring)
+ *
+ * This is a replacement for strncpy() uses where the source is not
+ * a NUL-terminated string.
+ *
+ * Note that sizes of @dest and @src must be known at compile-time.
+ */
+#define memtostr(dest, src) do { \
+ const size_t _dest_len = __builtin_object_size(dest, 1); \
+ const size_t _src_len = __builtin_object_size(src, 1); \
+ const size_t _src_chars = strnlen(src, _src_len); \
+ const size_t _copy_len = min(_dest_len - 1, _src_chars); \
+ \
+ BUILD_BUG_ON(!__builtin_constant_p(_dest_len) || \
+ !__builtin_constant_p(_src_len) || \
+ _dest_len == 0 || _dest_len == (size_t)-1 || \
+ _src_len == 0 || _src_len == (size_t)-1); \
+ memcpy(dest, src, _copy_len); \
+ dest[_copy_len] = '\0'; \
+} while (0)
+
/**
* memset_after - Set a value after a struct member to the end of a struct
*
I've also identified other cases where this pattern exists, so I think
we can apply this and any needed fixes using it instead of strscpy().
--
Kees Cook
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-08 23:19 ` Kees Cook
@ 2024-04-10 20:51 ` Justin Stitt
2024-04-10 21:14 ` Charles Bertsch
0 siblings, 1 reply; 19+ messages in thread
From: Justin Stitt @ 2024-04-10 20:51 UTC (permalink / raw)
To: Kees Cook; +Cc: Charles Bertsch, linux-scsi, MPT-FusionLinux.pdl
Hi,
On Mon, Apr 8, 2024 at 4:19 PM Kees Cook <keescook@chromium.org> wrote:
> I think something like this, memtostr:
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 9ba8b4597009..5def02c7c0ce 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -422,6 +422,30 @@ void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
> memcpy(dest, src, strnlen(src, min(_src_len, _dest_len))); \
> } while (0)
>
> +/**
> + * memtostr - Copy a possibly non-NUL-term string to a NUL-term string
> + * @dest: Pointer to destination NUL-terminates string
> + * @src: Pointer to character array (likely marked as __nonstring)
> + *
> + * This is a replacement for strncpy() uses where the source is not
> + * a NUL-terminated string.
> + *
> + * Note that sizes of @dest and @src must be known at compile-time.
> + */
> +#define memtostr(dest, src) do { \
> + const size_t _dest_len = __builtin_object_size(dest, 1); \
> + const size_t _src_len = __builtin_object_size(src, 1); \
> + const size_t _src_chars = strnlen(src, _src_len); \
> + const size_t _copy_len = min(_dest_len - 1, _src_chars); \
> + \
> + BUILD_BUG_ON(!__builtin_constant_p(_dest_len) || \
> + !__builtin_constant_p(_src_len) || \
> + _dest_len == 0 || _dest_len == (size_t)-1 || \
> + _src_len == 0 || _src_len == (size_t)-1); \
> + memcpy(dest, src, _copy_len); \
> + dest[_copy_len] = '\0'; \
> +} while (0)
> +
> /**
> * memset_after - Set a value after a struct member to the end of a struct
> *
>
>
> I've also identified other cases where this pattern exists, so I think
> we can apply this and any needed fixes using it instead of strscpy().
>
For visibility, Kees has a series [1] which introduces memtostr and
also fixes up drivers/message/fusion/mptsas.c.
Charles, can you try out that series?
> --
> Kees Cook
[1]: https://lore.kernel.org/all/20240410023155.2100422-2-keescook@chromium.org/
Thanks
Justin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: startup BUG at lib/string_helpers.c from scsi fusion mptsas
2024-04-10 20:51 ` Justin Stitt
@ 2024-04-10 21:14 ` Charles Bertsch
0 siblings, 0 replies; 19+ messages in thread
From: Charles Bertsch @ 2024-04-10 21:14 UTC (permalink / raw)
To: Justin Stitt, Kees Cook; +Cc: linux-scsi, MPT-FusionLinux.pdl
On 4/10/24 13:51, Justin Stitt wrote:
...
>
> For visibility, Kees has a series [1] which introduces memtostr and
> also fixes up drivers/message/fusion/mptsas.c.
>
> Charles, can you try out that series?
>
>> --
>> Kees Cook
>
> [1]: https://lore.kernel.org/all/20240410023155.2100422-2-keescook@chromium.org/
>
> Thanks
> Justin
Success!
I was able to apply the patches for include/linux/string.h and for
drivers/message/fusion/mptsas.c (as needed for this test hardware).
Clean build, identified as 6.9.0-rc3_64+. System boots. scsi interface
found, disks found, and some test scripts run successfully.
Thanks
Charles Bertsch
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2024-04-10 21:16 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-01 22:43 startup BUG at lib/string_helpers.c from scsi fusion mptsas Charles Bertsch
2024-04-03 23:20 ` Bart Van Assche
2024-04-04 19:58 ` Justin Stitt
2024-04-04 21:38 ` Justin Stitt
2024-04-04 21:53 ` James Bottomley
2024-04-04 22:04 ` Justin Stitt
2024-04-04 22:29 ` James Bottomley
2024-04-04 22:33 ` James Bottomley
2024-04-04 22:43 ` Martin K. Petersen
2024-04-04 22:47 ` Justin Stitt
2024-04-04 23:39 ` Kees Cook
2024-04-05 0:10 ` Justin Stitt
2024-04-05 0:12 ` Justin Stitt
2024-04-04 23:57 ` Kees Cook
2024-04-06 20:42 ` Charles Bertsch
2024-04-08 19:59 ` Justin Stitt
2024-04-08 23:19 ` Kees Cook
2024-04-10 20:51 ` Justin Stitt
2024-04-10 21:14 ` Charles Bertsch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.