Bug#1030524: iwd segfaults in 2.2-1 no armhf on Rasperry Pi

[Patrick Häcker]

Package: iwd
Version: 2.2-1
Severity: important

Dear Maintainer,

on a Raspberry Pi 4 with armhf, version 2.2-1 segfaults when starting.
2.1-1 works without segfault.

(gdb) run
Starting program: /usr/libexec/iwd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
No Diffie-Hellman support found, WPS will not be available
The following options are missing in the kernel:
CONFIG_KEY_DH_OPERATIONS
Wireless daemon version 2.2
Loaded configuration from /etc/iwd/main.conf
malloc(): invalid next size (unsorted)

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
(gdb) bt
#0 __libc_do_syscall ()
at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1 0xb6e8e42c in __pthread_kill_implementation (threadid=3070206496,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43
#2 0xb6e8e470 in __pthread_kill_internal (signo=6, threadid=<optimized out>)
at pthread_kill.c:78
#3 0xb6e5d322 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0xb6e4e0ac in __GI_abort () at abort.c:79
#5 0xb6e85ac6 in __libc_message (action=action@entry=do_abort,
fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:155
#6 0xb6e967fa in malloc_printerr (str=<optimized out>) at malloc.c:5660
#7 0xb6e98da2 in _int_malloc (av=0xb6f507a4 <main_arena>,
bytes=bytes@entry=60) at malloc.c:4001
#8 0xb6e99a5e in __GI___libc_malloc (bytes=60) at malloc.c:3315
#9 0xb6f77ab4 in l_malloc () from /lib/arm-linux-gnueabihf/libell.so.0
#10 0xb6f77bd0 in l_memdup () from /lib/arm-linux-gnueabihf/libell.so.0
#11 0xb6f7e284 in ?? () from /lib/arm-linux-gnueabihf/libell.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (820, 'testing'), (400, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.84-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iwd depends on:
ii init-system-helpers 1.65.2
ii libc6 2.36-8
ii libell0 0.56-2
ii libreadline8 8.2-1.3

Versions of packages iwd recommends:
ii dbus [dbus-system-bus] 1.14.4-1
ii wireless-regdb 2022.06.06-1

iwd suggests no packages.

-- Configuration Files:
/etc/iwd/main.conf changed:
[General]
EnableNetworkConfiguration=true
[Network]
EnableIPv6=true


-- no debconf information

[Jonas Smedegaard]

Quoting Patrick Häcker (2023-02-04 14:59:30)

> on a Raspberry Pi 4 with armhf, version 2.2-1 segfaults when starting.
> 2.1-1 works without segfault.

Thanks for the bugreport!

A new release 2.3-1 has just been released. It would be helpful if you
could test whether the problem has been fixed.

Upstream changes do not mention any RPi or ARM-related issues
specifically, but mentions an off-by-one error which perhaps could lead
to segfaults on your system.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private

[Patrick Häcker]

Hello Jonas,

> A new release 2.3-1 has just been released. It would be helpful if you
> could test whether the problem has been fixed.

I can confirm that the Debian package 2.3-1 works without segfault (have it
running for > 10 hours without a problem). Thanks for the quick packaging!

> Upstream changes do not mention any RPi or ARM-related issues
> specifically, but mentions an off-by-one error which perhaps could lead
> to segfaults on your system.

If I had to guess, I would think that it was an ABI mismatch resulting from a
missing versioned dependency/conflict in one of the related packages and
somehow related to being a 32-bit ARM system, which is probably not that
common in combination with iwd (and amd64 got a binary-only update, which
armhf did not get).

If that should be true, the issue could reappear in the future. Nevertheless,
I suggest to close this bug and do a more detailed analysis only if the issue
really reappears in the future.

Kind regards
Patrick