Re: [Qemu-devel] [PATCH] qemu-nbd: Ignore SIGPIPE

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Jun 28, 2017 at 04:27:00PM +0200, Max Reitz wrote:
> On 2017-06-27 19:09, Eric Blake wrote:
> > On 06/11/2017 07:37 AM, Max Reitz wrote:
> >> qemu proper has done so for 13 years
> >> (8a7ddc38a60648257dc0645ab4a05b33d6040063), qemu-img and qemu-io have
> >> done so for four years (526eda14a68d5b3596be715505289b541288ef2a).
> >> Ignoring this signal is especially important in qemu-nbd because
> >> otherwise a client can easily take down the qemu-nbd server by dropping
> >> the connection when the server wants to send something, for example:
> >>
> >> $ qemu-nbd -x foo -f raw -t null-co:// &
> >> [1] 12726
> >> $ qemu-io -c quit nbd://localhost/bar
> >> can't open device nbd://localhost/bar: No export with name 'bar' available
> >> [1]  + 12726 broken pipe  qemu-nbd -x foo -f raw -t null-co://
> >>
> >> In this case, the client sends an NBD_OPT_ABORT and closes the
> >> connection (because it is not required to wait for a reply), but the
> >> server replies with an NBD_REP_ACK (because it is required to reply).
> >>
> >> Signed-off-by: Max Reitz <mreitz@redhat.com>
> >> ---
> > 
> > As mentioned in another thread, I'm trying to figure out if this patch
> > belongs as a third patch to fix CVE-2017-9524, or whether we want to
> > open a second CVE by considering this a slightly different
> > denial-of-service attack than what my patches fixed.
> 
> I think nobody would rip our heads off if we added it to it... I think
> it's similar in the regard that the NBD server tries to send something
> to a client that is no longer there, so it crashes (aborting in the
> original case, due to SIGPIPE here).
> 
> But strictly speaking it's a different issue, even from the user's
> perspective: In the original case you kill the server using nmap, here
> you do so using a real NBD client. Hm, not sure, how hard is it to
> assign a new CVE? O:-)

Have we issued a patch for CVE-2017-9524 yet ?  If so, then we *must*
request a new CVE, because vendors will need to track it as an
additional fix to backport & ship, if they've already shipped the
previous fix.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|