Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jun 2018 15:45:57 +0200
From: Alexander Potapenko <>
To: Vladis Dronov <>
Subject: Re: CVE-2018-1000204: Linux kernel 3.18 to 4.16
 infoleak due to incorrect handling of SG_IO ioctl

On Fri, Jun 22, 2018 at 3:32 PM Vladis Dronov <> wrote:
> Hello, Alexander,
Hi Vladis,
> Could you please, explain, why do you think CVE-2018-1000204 is a security
> flaw?
> > The problem has limited scope, as users don't usually have permissions
> > to access SCSI devices. On the other hand, e.g. the Nero user manual
> > suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible.
> There is a check in the kernel in sg_build_indirect() exactly for this
> situation:
>         [drivers/scsi/sg.c]
>         if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
>                 gfp_mask |= __GFP_ZERO;
Yes, you're right. It appears unlikely that a user has both

> This means non-root user will get zero-ed pages even if it has o+rw access
> to /dev/sg*. Tests of your reproducer on systems available to me confirm
> this, i.e. non-root user gets a zero-ed out buffer even if it is able to
> access /dev/sg*.
> I may not got smth correctly, but for now I do not see CVE-2018-1000204
> as a security flaw and I believe a reject request to MITRE should be
> issued.
How do I proceed with this?
> Best regards,
> Vladis Dronov | Red Hat, Inc. | Product Security Engineer

Thank you,

Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ