iperf3: segfault on x86_64

[Djfe]

Maintainer: @nbd168
Environment: x86_64, Hewlett-Packard HP EliteDesk 800 G1 USDT, OpenWrt GCC 12.3.0 r23899+10-3001d3c5d4
This was an OpenWrt fork: Gluon v2023.2.3
Which runs:

OPENWRT_REPO=https:/openwrt/openwrt.git
OPENWRT_BRANCH=openwrt-23.05
OPENWRT_COMMIT=3001d3c5d446bf53fc222640d49a4cc79e04a2f3

Description:
I just noticed this segfault in dmesg after running a couple of iperf3 commands (I'm not sure which one triggered it or if it could've been triggered by a STRG+C by accident)

[459397.930023] iperf3[4064]: segfault at 28 ip 00007ff50794da40 sp 00007ffe5a472880 error 4 in libc.so[7ff507928000+4c000] [459397.930195] Code: 41 5d 41 5e c3 48 8d 35 2e f2 03 00 e9 a1 ff ff ff 90 83 c8 ff c3 83 c8 ff c3 83 c8 ff c3 41 54 55 bd 01 00 00 00 53 48 89 fb <48> 8b 43 28 48 85 c0 74 08 48 ff c5 48 89 c3 eb ef 48 0f bf 43 50 

[Djfe]

I forgot to mention @nbd168 (had to edit the post above)

[vincejv]

This seems like an upstream issue? I can reproduce it with other linux distros as well

[Djfe]

how did you reproduce it? Just by running iperf3 or a special command?

[vincejv]

@Djfe see upstream
esnet/iperf#1694
esnet/iperf#1692
esnet/iperf#1681

It seems that the server crash because it receives "illegal" message from the client, and somehow it doesn't know to handle it well

I get this seg fault when i abruptly stop the client from performing the iperf test and then resuming with another client on the same port

[neheb]

Not fixed by 37ade7e ?

[vincejv]

@neheb x86_64 is little endian so that fix isn't applicable

[neheb]

It relates to JSON code.

Anyway, gdb is needed to figure this out.