emhttpd segfaults (NULL deref in libc AVX) during cmdStart=Start on 7.2.4

[GeiserX]

Bug Description

emhttpd crashes with a reproducible segfault every time the array start is triggered (via WebUI button or emcmd "cmdStart=Start"). The array never transitions from STOPPED to STARTED. The crash is 100% reproducible across dozens of attempts.

Environment

• Unraid version: 7.2.4 (upgraded from 7.2.3)
• Previous version: 7.2.3 (Dec 18, 2025) — array started fine on this version
• Hardware: Custom build, 1x parity + 7x data (ST4000NE/VN 4TB), 2x NVMe cache (ZFS mirror), 2x SSD pool (ZFS mirror)
• Array config: 9 slots (0-7 active, slot 29 disabled/empty — DISK_NP_DSBL)

Crash Details

emhttpd[PID]: segfault at 0 ip XXXX15a387 sp XXXX error 4 in libc-2.42.so[182387,...]
Code: ... <c5> fe 6f 07 c5 fd 74 0e c5 85 74 d0 c5 ed df c9 c5 fd d7 c9 ff c1

• Faulting instruction: vmovdqu ymm0, [rdi] — AVX2-optimized string function (likely __strcmp_avx2 or __strlen_avx2)
• Fault address: 0x0 (NULL pointer dereference)
• Error code: 4 (user-mode read, page not present)
• Offset in libc: 0x15A387 (consistent across all crashes — same code path every time)
• Crash location: Always in a libc string function; rdi=0 means a NULL string pointer was passed

Sequence of Events

1. emhttpd starts, reads SMART data for all disks — succeeds
2. md driver imports all 29 slots (0-28) via /proc/mdcmd — succeeds
3. cmd startArray is sometimes sent to the kernel before the crash, sometimes not (timing varies)
4. emhttpd segfaults 6–26 seconds after the last import, during post-import / pre-mount processing
5. Array remains STOPPED, disks never mount

What Was Ruled Out

Attempted fix	Result
Safe mode (/boot/unraidsafemode)	Still crashes — not a plugin issue
Removed stale NFS/SMB remote shares from unassigned.devices	Still crashes
Removed conflicting entries in unassigned.devices.cfg (array disks listed as unassigned)	Still crashes
Pre-imported ZFS pools before start	emhttpd sometimes survived init but crashed on startArray
Clean md module reload (rmmod md_mod && modprobe md_mod)	Imports work, but cmd startArray via /proc/mdcmd returns EINVAL — emhttpd uses a privileged path
Checked all .cfg files for NULL bytes / corruption	No corruption found
Verified flash filesystem (vfat) integrity	No errors

Likely Root Cause

emhttpd passes a NULL string to a libc function during array-start processing. Possible triggers:

• Disabled disk slot 29 (DISK_NP_DSBL) with sparse config keys (only diskIdSlot.29, diskSpindownDelay.29, diskSpinupGroup.29 — no diskFsType, diskExport, etc.)
• Processing of a config value that exists for active disks but is absent for disabled slots
• sbSyncExit=-4 (unclean shutdown) combined with mdNumInvalid=1

Coredump Available

A 13MB coredump was captured at /tmp/core.emhttpd.55426 on the affected system. Happy to provide if needed.

Workaround

Downgrading to 7.2.3 (swapping /boot/previous/ files) to restore array functionality. Will report whether 7.2.3 starts the array successfully.

[GeiserX]

Update: Root cause identified — corrupt super.dat

After extensive debugging, the root cause is not version-specific. The same segfault reproduces on both 7.2.3 and 7.2.4.

Root cause

The binary file /boot/config/super.dat (disk-to-slot assignment mapping) was corrupt. When emhttpd processes cmdStart=Start, it reads super.dat and passes a field value to a libc string function (strlen or strcmp via AVX2-optimized vmovdqu ymm0, [rdi]). The corrupt file produces a NULL pointer for one of these fields, causing the segfault.

Evidence

• Renaming super.dat → super.dat.disabled and restarting emhttpd: no crash. emhttpd creates a fresh empty super.dat and stays alive.
• Reassigning all disks from the WebGUI (fresh super.dat): array starts normally.
• The crash reproduced identically on 7.2.3 and 7.2.4 with the same super.dat file.
• The corruption likely originated from a failing USB flash drive (bad sectors confirmed — consistent I/O errors at sector ~1,983,400 during Linux boot, xHCI disconnect under sustained reads).

The bug

emhttpd should validate super.dat contents before use and report a meaningful error (e.g., "corrupt disk configuration — please reassign disks") instead of segfaulting. A NULL string pointer from a corrupt binary config file should never reach libc unchecked.

Workaround

1. Stop emhttpd
2. Rename /boot/config/super.dat to /boot/config/super.dat.corrupt
3. Start emhttpd (creates fresh super.dat)
4. Reassign all disks to their correct slots from the WebGUI
5. Check "Parity is already valid" and start the array