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

[Philippe Mathieu-Daudé]

On 1/24/20 2:52 PM, Kevin Wolf wrote:
> 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.

Good point :) error_report_once() then!