linux-kernel - Re: [GIT PULL] SCSI fixes for 4.7-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFw5xsPx0r01Z5aKXn6UbHLhGbXoa0qyGVJbfWiC7yq1WA@mail.gmail.com>
Date:	Sat, 11 Jun 2016 13:25:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	"Ewan D. Milne" <emilne@...hat.com>,
	Jan Stancek <jstancek@...hat.com>,
	Johannes Thumshirn <jthumshirn@...e.de>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 4.7-rc2

On Sat, Jun 11, 2016 at 12:41 PM, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> The QEMU people have accepted it as their bug and are fixing it.

Of course they are. Somebody found a bug in their device model, I'd
expect nothing else.

But I'm not worried about qemu. I'm worried about all the other random
devices that have never been tested.

>  There's no other course of action, really because we can't stop people
> sending this command using the BLOCK_PC interface from user space, so
> it's now a known and easy to use way of stopping the device from
> responding.

Bah. That's not an argument from kernel space. We've had that forever.
Broken device that hangs up when you try to read past the end? If you
can open the raw device for reading, you can still do a
SCSI_IOCTL_SEND_COMMAND to send that read command past the end.

The fact that you can craft special commands that can cause problems
for specific devices (if you have access to the raw device) does *not*
at all argue that the kernel should then do those accesses of its own
volition.

My worry basically comes down to: we're clearly now doing something
that has never ever been tested by anybody before.

And I think that the assumption that the bug would magically be
limited to qemu is a *big* assumption.

                Linus