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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190201140852.GA20335@kroah.com>
Date:   Fri, 1 Feb 2019 15:08:52 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Jann Horn <jannh@...gle.com>
Cc:     kernel list <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 095/103] bpf: prevent out of bounds speculation on
 pointer arithmetic

On Fri, Feb 01, 2019 at 03:00:18PM +0100, Jann Horn wrote:
> On Tue, Jan 29, 2019 at 12:47 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > 4.19-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > [ commit 979d63d50c0c0f7bc537bf821e056cc9fe5abd38 upstream ]
> >
> > Jann reported that the original commit back in b2157399cc98
> > ("bpf: prevent out-of-bounds speculation") was not sufficient
> > to stop CPU from speculating out of bounds memory access:
> > While b2157399cc98 only focussed on masking array map access
> > for unprivileged users for tail calls and data access such
> > that the user provided index gets sanitized from BPF program
> > and syscall side, there is still a more generic form affected
> > from BPF programs that applies to most maps that hold user
> > data in relation to dynamic map access when dealing with
> > unknown scalars or "slow" known scalars as access offset, for
> > example:
> 
> Is this also going into 4.14 and 4.9? I don't see anything related in
> the stable queue or in stable-rc.

Ah, the original submitter did not send backported patches, but you are
right, it should go further back.  I'll see how hard it would be to do
the backport, thanks for letting me know.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ