[Jack-Devel] segfault in libjack from incorrect regex in jack_get_ports()

Jörn Nettingsmeier nettings at stackingdwarves.net
Sat Feb 23 23:17:54 CET 2019


On 2/19/19 10:03 PM, Thomas Brand wrote:
> Hi Jörn,
> 
> On Sat, February 16, 2019 19:33, Jörn Nettingsmeier wrote:
>> Hi guys,
>>
>>
>>
>> I'm seeing segfaults caused by an incorrect regex (found while fooling
>> around to see what syntax is allowed, since it's not really documented).
>>
>> Turns out the correct answer to that is "regexec.c", and thus, POSIX
>> regexes. Someone might want to put that in the docs somewhere.
>>
>> Thread 1 "shairport-sync" hit Breakpoint 1, jack_init (argc=<optimized
>> out>, argv=<optimized out>) at audio_jack.c:221 221	  if
>> (config.jack_autoconnect_pattern != NULL) {
>> (gdb) print config.jack_autoconnect_pattern
>> $1 = 0x5c8a0 "effect_1:in{L|R}"
>>
>>
>> ^--- this is likely the problem
>>
>>
>> (gdb) step
>> 222	    debug(1, "config.jack_autoconnect_pattern is %s.",
>> config.jack_autoconnect_pattern); (gdb) next
>> 223	    const char** port_list = jack_get_ports(client,
>> config.jack_autoconnect_pattern, (gdb) step
>>
>>
>> Thread 1 "shairport-sync" received signal SIGSEGV, Segmentation fault.
>> 0x76847e8c in __regexec (preg=<optimized out>, string=0x71801e34
>> "system:playback_1", nmatch=0, pmatch=0x0,
>> eflags=0) at regexec.c:243 243	regexec.c: No such file or directory.
>> (gdb) bt
>> #0  0x76847e8c in __regexec (preg=<optimized out>, string=0x71801e34
>> "system:playback_1", nmatch=0, pmatch=0x0,
>> eflags=0) at regexec.c:243 #1  0x76f1d0f4 in ?? () from
>> /usr/lib/arm-linux-gnueabihf/libjack.so.0
>> #2  0x76f1d1c4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
>> #3  0x0002c988 in jack_init (argc=<optimized out>, argv=<optimized out>)
>> at audio_jack.c:223 #4  0x00016adc in main (argc=1, argv=0x7efffc54) at
>> shairport.c:1474
>>
>>
>> It turns out that the return value of regcomp is not checked by libjack.
>> That's the last point where a segfault can be prevented from a simple
>> syntax error. The only way to catch that in the application is to set up an
>> entirely redundant regex scaffold and check the regcomp return value,
>> before throwing it all away and letting libjack do the work all over
>> again.
>>
>> In the case of configurable auto-connect patterns, which many JACK
>> clients now offer as a sane and useful replacement of auto-connecting to
>> system:playback_N, this SEGV is triggered by end-user action, not
>> programmer mistake. That's a harsh user experience, and should be fixed. A
>> brief look at the source seems to indicate the problem also exists in
>> jack1.
>>
>> I don't really feel qualified to tackle this myself, since it will
>> require lots of error handling in a multi-threaded library, which I don't
>> know too much about... glad to help testing, though.
>>
> 
> interesting observation .. I'd like to copy/paste this 1:1 to jack2 github
> issues so it doesn't get lost, any objections?
> Greetings


Sorry, seeing this only now. Of course not, and thanks for the quick 
fix! It's good to know the github issues are being watched, I'll move my 
reports there in the future.

Thanks to all active JACK maintainers! Of course we all know it's pretty 
much done, but it's still good to know people familiar with the inner 
workings are still there to apply fixes.


-- 
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net



More information about the Jackaudio mailing list