Re: segfault in libjack from incorrect regex in jack_get_ports()

"Thomas Brand" <[email protected]>
Newsgroups gmane.comp.audio.jackit
Message-ID <[email protected]>
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


_______________________________________________
Jack-Devel mailing list
[email protected]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.