Re: iwd 2.22 segfault

[James Prestwood <prestwoj@gmail.com>]

Hi Jules,

On 10/3/24 5:01 AM, Jules Maselbas wrote:
> Hi,
>
> I am having a segfault in iwd 2.22, running on Alpine Linux (on edge).
>
> I can reproduce the segfault by doing `rc-service networking restart`,
> dmesg gives this information:
>
> iwd[4229]: segfault at a ip 00007f027ca94c6b sp 00007fffd6c75858 error 4 in ld-musl-x86_64.so.1[7f027ca44000+57000] likely on CPU 4 (core 2, socket 0)
> Code: f8 48 83 fa 08 72 14 f7 c7 07 00 00 00 74 0c a4 48 ff ca f7 c7 07 00 00 00 75 f4 48 89 d1 48 c1 e9 03 f3 48 a5 83 e2 07 74 05 <a4> ff ca 75 fb c3 48 89 f8 48 29 f0 48 39 d0 0f 83 bf ff ff ff 48
> ...
> iwd[24403]: segfault at a ip 00007fa91633ac6b sp 00007ffd1faaa028 error 4 in ld-musl-x86_64.so.1[7fa9162ea000+57000] likely on CPU 6 (core 3, socket 0)
> Code: f8 48 83 fa 08 72 14 f7 c7 07 00 00 00 74 0c a4 48 ff ca f7 c7 07 00 00 00 75 f4 48 89 d1 48 c1 e9 03 f3 48 a5 83 e2 07 74 05 <a4> ff ca 75 fb c3 48 89 f8 48 29 f0 48 39 d0 0f 83 bf ff ff ff 48
>
> This is not an issue in musl-libc, but a call to memcpy with a bad address,
> we can see that the source address is 0xa (10) which is also the offset of `aa` field in the `netdev->handshake` struct
> which makes me think that handshake is null when netdev_rssi_poll is called.
>
> Here is a backtrace when iwd segfault:
> (gdb) bt
> #0  memcpy () at src/string/x86_64/memcpy.s:22
> #1  0x00005555555fc0dc in memcpy (__od=<optimized out>, __os=0xa, __n=6) at /usr/include/fortify/string.h:55
> #2  l_netlink_message_append (message=0x7ffff7f34050, type=type@entry=6, data=0xa, len=len@entry=6) at ell/netlink.c:841
> #3  0x00005555555fd78f in l_genl_msg_append_attr (msg=msg@entry=0x7ffff7f34020, type=type@entry=6, len=len@entry=6, data=<optimized out>) at ell/genl.c:1518
> #4  0x0000555555559080 in netdev_rssi_poll (timeout=<optimized out>, user_data=0x7ffff7f38dc0) at src/netdev.c:760
> #5  0x00005555555f959e in timeout_callback (fd=<optimized out>, events=<optimized out>, user_data=0x7ffff7f363b0) at ell/timeout.c:69
> #6  timeout_callback (fd=<optimized out>, events=<optimized out>, user_data=0x7ffff7f363b0) at ell/timeout.c:58
> #7  0x00005555555f8a75 in l_main_iterate (timeout=<optimized out>) at ell/main.c:461
> #8  0x00005555555f8b4e in l_main_run () at ell/main.c:508
> #9  l_main_run () at ell/main.c:490
> #10 0x00005555555f8d7f in l_main_run_with_signal (callback=callback@entry=0x5555555587f0 <signal_handler>, user_data=user_data@entry=0x0) at ell/main.c:630
> #11 0x0000555555557bd0 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:614
>
>
> I've also ran a git bisect which points to
> 154a29be0552f5a39e34301ebaf24623d64073da netdev: fall back to RSSI polling if SET_CQM fails
> as the first bad commit. I noticed the "rssi" word is also present in the stacktrace.

Thanks for such detailed info, do you happen to have debug logs when 
this happens? I'm just trying to see the code path which leads to this. 
I can't seem to reproduce it but I suspect musl-libc is just different 
enough that its exposing the bug


>
> I am using the following wifi card:
> 03:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
> driver: mt7921e
> version: 6.6.53-0-lts
> firmware-version: ____000000-20240716163327
> expansion-rom-version:
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: no
>
>
> Cheers,
> Jules
>
>
Thanks,

James