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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ