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]

Message-Id: <974d7fcb-efbb-4508-a4cb-4b5328669c14@app.fastmail.com>
Date:   Wed, 30 Nov 2022 17:13:18 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jason A . Donenfeld" <Jason@...c4.com>
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 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. Again, I'm not saying that your code is
vulnerable to that type of attack, just that making all ABI
structures not have holes is useful for auditing.

    Arnd