linux-kernel - Re: [PATCH] efi: READ_ONCE rng seed size before munmap

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: <20200217155402.GB1461852@kroah.com>
Date:   Mon, 17 Feb 2020 16:54:02 +0100
From:   Greg KH <greg@...ah.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH] efi: READ_ONCE rng seed size before munmap

On Mon, Feb 17, 2020 at 04:23:03PM +0100, Ard Biesheuvel wrote:
> On Mon, 17 Feb 2020 at 13:34, Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > This function is consistent with using size instead of seed->size
> > (except for one place that this patch fixes), but it reads seed->size
> > without using READ_ONCE, which means the compiler might still do
> > something unwanted. So, this commit simply adds the READ_ONCE
> > wrapper.
> >
> > Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
> > Cc: Ard Biesheuvel <ardb@...nel.org>
> > Cc: stable@...r.kernel.org
> 
> Thanks Jason
> 
> I've queued this in efi/urgent with a fixes: tag rather than a cc:
> stable, since it only applies clean to v5.4 and later.

Why do that?  That just makes it harder for me to know to pick it up for
5.4 and newer.

> We'll need a
> backport to 4.14 and 4.19 as well, which has a trivial conflict
> (s/add_bootloader_randomness/add_device_randomness/) but we'll need to
> wait for this patch to hit Linus's tree first.

Ok, if you are going to send it on to me for stable, that's fine, but
usually you can just wait for the rejection notices for older kernels
before having to worry about this.  In other words, you are doing more
work than you have to here :)

thanks,

greg k-h