qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711)


From: Kevin Wolf
Subject: Re: [PATCH] iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711)
Date: Fri, 24 Jan 2020 14:52:13 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 24.01.2020 um 14:42 hat Philippe Mathieu-Daudé geschrieben:
> On 1/24/20 2:39 PM, Kevin Wolf wrote:
> > Am 24.01.2020 um 11:48 hat Felipe Franciosi geschrieben:
> > > On Jan 24, 2020, at 10:04 AM, Philippe Mathieu-Daudé <address@hidden> 
> > > wrote:
> > > > Also shouldn't we report some warning in case of such invalid
> > > > request? So the management side can look at the 'malicious iSCSI
> > > > server'?
> > > 
> > > I think having the option to do so is a good idea. There are two cases
> > > I can think of that you run into a "malicious" storage server:
> > > 1) Someone hacked your storage server
> > > 2) Your control plane allows your compute to connect to a user
> > > provided storage service
> > > 
> > > Thinking as an admin, if I only allow storage servers I provide, then
> > > I want to see such warnings. If I let people point the VMM to dodgy
> > > servers, then I probably don't want the log spam.
> > 
> > For this reason, we generally don't log things for failed I/O requests.
> > If we wanted to introduce it, we'd better find a way to do so
> > consistently everywhere and not just in a single place with a one-off
> > option.
> 
> I'm just suggesting to use error_report().

If you do this unconditionally with an untrusted server, you allow it to
DoS you by filling up your disk with error logs.

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]