linux-kernel - Re: [PATCH v10 3/4] random: introduce generic vDSO getrandom() implementation

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]

Date:   Wed, 30 Nov 2022 17:40:40 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Florian Weimer <fweimer@...hat.com>, linux-kernel@...r.kernel.org,
        patches@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>,
        linux-crypto@...r.kernel.org, linux-api@...r.kernel.org,
        x86@...nel.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
        Carlos O'Donell <carlos@...hat.com>,
        Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v10 3/4] random: introduce generic vDSO getrandom()
 implementation

On Wed, Nov 30, 2022 at 05:13:18PM +0100, Arnd Bergmann wrote:
> On Wed, Nov 30, 2022, at 16:47, Jason A. Donenfeld wrote:
> 
> >> > There's padding at the end of the structure, yes. But both
> >> > `generation` and `is_ready` will be at the same offset. If the
> >> > structure grows, then sure, that'll have to be taken into account. But
> >> > that's not a problem because this is a private implementation detail
> >> > between the vdso code and the kernel.
> >>
> >> I was not concerned about incompatibility here, but rather about
> >> possibly leaking kernel data to the vdso page.
> >
> > The vvar page starts out zeroed, no?
> 
> The typical problem is someone doing a copy_to_user() of an in-kernel
> structure into the userspace side, which would then copy the
> padding as well. If the source is on the stack, a malicious caller
> can trick the another syscall into leaving sensitive data at this
> exact stack location.

I'm quite aware of this infoleak, having made use of it countless times
over the years. It just doesn't seem relevant to the vvar page.

Jason