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

[Thomas Brand]

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