znc: "stack smashing" segmentation fault with znc-git on armv7h

I’m running znc-git from the AUR on my ODROID-XU4, running Arch Linux ARM, after adding armv7h to the architecture field. Things were fine until I decided to update/rebuild yesterday.

After between 15m-1h of being online, the service suddenly stops.

[alarm@alarm ~]$ znc -v
ZNC 1.7.x-git-836-4a3f62f1 - https://znc.in
IPv6: yes, SSL: yes, DNS: threads, charset: yes, i18n: no, build: autoconf
[alarm@alarm ~]$ systemctl status znc
● znc.service - ZNC, an advanced IRC bouncer
   Loaded: loaded (/usr/lib/systemd/system/znc.service; enabled; vendor preset: disabled)
   Active: failed (Result: core-dump) since Mon 2017-11-20 22:30:02 GMT; 12h ago
  Process: 12211 ExecStart=/usr/bin/znc -f (code=dumped, signal=ABRT)
 Main PID: 12211 (code=dumped, signal=ABRT)

Nov 20 21:50:18 alarm znc[12211]: Adding server [irc.rizon.net +6697]...
Nov 20 21:50:18 alarm znc[12211]: Loading user module [chansaver]...
Nov 20 21:50:18 alarm znc[12211]: Loading user module [controlpanel]...
Nov 20 21:50:18 alarm znc[12211]: Loading user module [log]...
Nov 20 21:50:18 alarm znc[12211]: Loading user module [cert]...
Nov 20 21:50:18 alarm znc[12211]: Staying open for debugging [pid: 12211]
Nov 20 21:50:18 alarm znc[12211]: ZNC 1.7.x-git-836-4a3f62f1 - https://znc.in
Nov 20 22:30:02 alarm znc[12211]: *** stack smashing detected ***: <unknown> terminated
Nov 20 22:30:02 alarm systemd[1]: znc.service: Main process exited, code=dumped, status=6/ABRT
Nov 20 22:30:02 alarm systemd[1]: znc.service: Failed with result 'core-dump'.

I would report this in IRC, but none of my clients are set up for direct connection, only through my ZNC session.

If there’s any additional info which would be helpful, please just ask; I’ll be more than happy to generate/provide it.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 31 (13 by maintainers)

Most upvoted comments

It appears to be a bug in ICU, where multibyte sequences may be written beyond the end of the output buffer, erasing part of the stack canary. I filled info about the bug upstream: https://ssl.icu-project.org/trac/ticket/13490

Bonstra on Dec 8, 2017

Maybe he should. But it was me who added encodings support to Csocket. @jimloco

It doesn’t detect the case where the pivotbuf has run out of space

In what cases 100 bytes can be not enough for the pivot? AFAIR, I wrote it this way to make sure both cases are triggered often: the whole string fits, and single call to ucnv_convertEx is enough; the input string is bigger than the buffer, so that ucnv_convertEx is called several times.

DarthGandalf on Dec 7, 2017

So, apparently it is ucnv_convertEx from icu that causes the stack smash. I stared a bit at icoConv() and the API docs for ucnv_convertEx and could not spot anything wrong. Also, the list of changes for icu do not suggest anything interesting here. Oh and: why does this only seem to affect ARM? I took a quick look at https://wiki.debian.org/ArchitectureSpecificsMemo and the difference between amd64 and arm64 mostly seems to be signed/unsigned char. Hm… 😦

psychon on Nov 27, 2017

I’m facing the same issue on ArchLinuxArm running on an ARMv5 machine. I can confirm it is related to the recent icu upgrade to 60.1. ZNC appears to crash while translating charsets for the result of a WHO command, for some users whose real name contains non-ASCII characters. Here is the stack trace I could get: https://gist.github.com/Bonstra/f38a184d0af66ee71d0dc9f8936db65c

I rebuilt znc with the --disable-charset option, and could not reproduce the bug after that.

Bonstra on Nov 26, 2017