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

[Thadeu Lima de Souza Cascardo]

On Wed, May 17, 2023 at 02:13:17PM +0200, Stefan Bader wrote:
> On 17.05.23 13:55, Thadeu Lima de Souza Cascardo wrote:
> > On Wed, May 17, 2023 at 09:18:38AM +0200, 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.
> > > -- 
> > > - Stefan
> > > 
> > 
> > Provenance here is stated on the "[Upstream commit SHA1]" lines at the top,
> > just like other fixes coming from upstream stable. As stated in the cover
> > letter, these were picked as submitted by the maintainer to the stable 4.14.y
> > series, hence the provenance as is.
> 
> The format like stable would suggest some stable but then not clearly which
> one. I realize that the stable series patches are done without that. But
> then at least have a tracking bug that tellls from where things come and
> also have a final commit which shows the upstream heritage.
> Information from the cover email gets lost in the tree itself. And take some
> comments as the pick was done before actually landing in 4.14.y. In this
> case I probably still would have added cherry pick lines but saying
> something from linux4.14.y submission). So we retrain the special way of
> getting them.

What about a Link: pointing out to lore, as upstream has been using? That would
be one step further than using the Message-ID, as those links include those.

In this particular case, there is where they came from, a mailbox, not a git
repo, so there would be no SHA1 to use, except one I created myself when
applying the fix myself.

Cascardo.

> > 
> > Just like with the other changes that come from upstream stable, this works
> > (and should, otherwise it would fail with those changes) for our tooling.
> > 
> > And since these are targeted to be released before May 31st, when Bionic goes
> > into ESM, I opted to handle this as usual.
> > 
> > Cascardo.
> 
> -- 
> - Stefan
>