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 <mre...@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
signature.asc
Description: OpenPGP digital signature
