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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

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:-)

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 498 bytes --]