[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: Tue, 28 Jan 2020 13:30:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

Hi guys,

(Cc'ing Jon)

On 1/23/20 5:59 PM, Kevin Wolf wrote:
Am 23.01.2020 um 13:44 hat Felipe Franciosi geschrieben:
When querying an iSCSI server for the provisioning status of blocks (via
GET LBA STATUS), Qemu only validates that the response descriptor zero's
LBA matches the one requested. Given the SCSI spec allows servers to
respond with the status of blocks beyond the end of the LUN, Qemu may
have its heap corrupted by clearing/setting too many bits at the end of
its allocmap for the LUN.

A malicious guest in control of the iSCSI server could carefully program
Qemu's heap (by selectively setting the bitmap) and then smash it.

This limits the number of bits that iscsi_co_block_status() will try to
update in the allocmap so it can't overflow the bitmap.

Signed-off-by: Felipe Franciosi <address@hidden>
Signed-off-by: Peter Turschmid <address@hidden>
Signed-off-by: Raphael Norwitz <address@hidden>

Thanks, applied to the block branch.

We are trying to reproduce this, do you already have some code that triggered this issue?

I am new to the block API, I noticed the block/blkdebug.c file with 'blkdebug' option, is it helpful to reproduce this issue via HMP?

Any suggestion what would be the easier/quicker way to test this?

Looking for iotests examples I see tests/qemu-iotests/147 providing a BuiltinNBD class. Is it the recommended way to go, to mock a iSCSI server?



reply via email to

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