Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 May 2017 15:05:34 +0200
From: Florian Weimer <>
To: Daniel Micay <>,
Cc: Roee Hay <>
Subject: Re: Linux kernel: stack buffer overflow with
 controlled payload in get_options() function

On 05/30/2017 03:02 PM, Daniel Micay wrote:
> On Tue, 2017-05-30 at 14:52 +0200, Florian Weimer wrote:
>> On 05/30/2017 01:51 PM, Daniel Micay wrote:
>>> It's unreasonable to consider the kernel line untrusted. A CVE being
>>> issued for one of these issues didn't make sense.
>> It's a potential Secure Boot bypass, so it matters in some theoretical
>> sense to some downstreams which carry those Secure Boot patches.
>> (Although I have yet to see anyone to revoke a signature on a kernel
>> with known root-to-ring-0 escalations, so the practical impact isn't
>> large because an attack could still downgrade to a kernel with an
>> exploitable vulnerability.)
>> Florian
> How is it a secure boot bypass? If the secure boot implementation
> doesn't cover the kernel line it's already broken.

That's not how the Secure Boot patches work.  They restrict some
features so that they cannot be selected from the kernel command line
(or later from userland), and they do not rely on a bootloader which
does not provide any means for editing the kernel command line.

> The provided example was treated as a verified boot vulnerability by
> Google and fixed. It isn't supposed to be possible to set the kernel
> line with a locked bootloader on Nexus/Pixel devices. It was a bug.

I don't know how Google's user lockout works, so I can't comment on that.


Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.