[SRU Bionic 0/5] CVE-2023-32233

[Thadeu Lima de Souza Cascardo]

On Wed, May 17, 2023 at 12:39:27PM +0100, Andrei Gherzan wrote:
> On 23/05/17 01:28PM, Stefan Bader wrote:
> > On 17.05.23 13:16, Andrei Gherzan wrote:
> > > On 23/05/17 09:18AM, Stefan Bader wrote:
> > > > On 16.05.23 15:53, Thadeu Lima de Souza Cascardo wrote:
> > > > > [Impact]
> > > > > On systems where user namespaces can be created by unprivileged users,
> > > > > which is the default configuration on Ubuntu, unprivileged users can
> > > > > trigger a use-after-free vulnerability on netfilter. This could be used to
> > > > > crash the system or elevate privileges.
> > > > > 
> > > > > [Test case]
> > > > > A reproducer that causes an oops under slub_debug=FZP was tested and the fix
> > > > > has been shown to prevent it.
> > > > > 
> > > > > [Backport]
> > > > > Picked patches submitted by the maintainer to 4.14 tree.
> > > > > 
> > > > > [Potential impact]
> > > > > netfilter users may find regressions when manipulating nftables.
> > > > > 
> > > > > Florian Westphal (1):
> > > > >     netfilter: nf_tables: split set destruction in deactivate and destroy
> > > > >       phase
> > > > > 
> > > > > Pablo Neira Ayuso (4):
> > > > >     netfilter: nf_tables: unbind set in rule from commit path
> > > > >     netfilter: nf_tables: use-after-free in failing rule with bound set
> > > > >     netfilter: nf_tables: bogus EBUSY when deleting set after flush
> > > > >     netfilter: nf_tables: deactivate anonymous set from preparation phase
> > > > > 
> > > > >    include/net/netfilter/nf_tables.h |  30 ++++++-
> > > > >    net/netfilter/nf_tables_api.c     | 139 +++++++++++++++++++++---------
> > > > >    net/netfilter/nft_dynset.c        |  22 ++++-
> > > > >    net/netfilter/nft_immediate.c     |   6 +-
> > > > >    net/netfilter/nft_lookup.c        |  21 ++++-
> > > > >    net/netfilter/nft_objref.c        |  21 ++++-
> > > > >    6 files changed, 193 insertions(+), 46 deletions(-)
> > > > > 
> > > > 
> > > > All patches seem to miss the cherry pick/backport line. As we probably also
> > > > should start handling bionic like ESM, maybe this should be re-submitted
> > > > with fixed provenance to the ESM list. Not NACKing straight to leave the
> > > > option for alternatives.
> > > 
> > > I had the same question for Thadeu, as I needed to understand his cover
> > > letter details. The idea is that the patches are from a maintainer
> > > submission against 4.14 that where picked by Thadeu for our 4.15. So
> > > these are not cherry-picked/backported per se, hence not having the
> > > specific footer.
> > > 
> > > The only change that Thadeu made was to adapt the maintainer's
> > > "[backport for 4.14 of SHA1]" line to match the autotriage format:
> > > "[Upstream commit SHA1]".
> > > 
> > 
> > There would be
> > 
> > (cherry picked from <SHA1> linux-4.14.y)
> > 
> > no?
> 
> Checking the stable branch, you are right. They have landed in stable
> 4.14.y, so we should add a cherry-pick line. 

But I submitted before they were there, so there were no SHA1s from
linux-4.14.y to use. By the way, my inbox shows the announced release of that
4.14 kernel containing those fixes after this message I am replying to.

Next time, I will make sure to make it clearer in the cover letter that this is
the case.


> 
> On the other hand, Thadeu found some fixes needed for these patches that
> weren't included in this version, so a v2 might come soon.

I am still evaluating if those would be really necessary.

Cascardo.

> -- 
> Andrei Gherzan