|
Message-ID: <538F3FBE.8070001@gmail.com> Date: Wed, 04 Jun 2014 21:48:14 +0600 From: "Alexander E. Patrakov" <patrakov@...il.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request: PulseAudio crash due to empty UDP packet 04.06.2014 21:30, cve-assign@...re.org wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> If one has module-rtp-recv loaded into PulseAudio, then a remote >> attacker can crash this instance of PulseAudio by sending an empty UDP >> packet > >> memblock.c: Assertion 'b' failed > > Use CVE-2014-3970. Thanks! >> PulseAudio usually gets respawned anyway. > > Apparently there are realistic circumstances in which respawning > doesn't happen (possibly a zero value of conf->daemonize or the > "User-configured server at %s, refusing to start/autospawn." case in > http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/daemon/main.c). Yes, there is a parameter in the daemon.conf configuration file that allows the user to turn the autospawn off. >> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-May/020740.html > >> expecting to find an infinite loop (as it would be common for such >> FIONREAD misuse), but found an assertion failure instead. So there may >> be two bugs. > > The scope of CVE-2014-3970 does not include any infinite loop that > might be discovered later. I have tested the patch, and it survives the empty packet without the infinite loop. Besides, after the patch, there is no code path in which recvmsg() is not called after a successful FIONREAD ioctl (even if it returns a zero size). So, any FIONREAD-related infinite loop that possibly remains on the RTP reception path after the patch is to be found on the path where the ioctl itself fails. -- Alexander E. Patrakov
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.