[Top][All Lists]

[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: Philippe Mathieu-Daudé
Subject: Re: [PATCH] iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711)
Date: Fri, 24 Jan 2020 15:24:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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

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

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!

reply via email to

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