ACK/Cmnt: [PATCH 0/3][B/G/oem-5.6] CVE-2021-29650: xtables membarrier DoS

[Kamal Mostafa]

On Thu, Apr 8, 2021 at 5:04 AM Tim Gardner <tim.gardner at canonical.com>
wrote:

>
>
> On 4/8/21 2:01 AM, Stefan Bader wrote:
> > On 06.04.21 16:45, Tim Gardner wrote:
> >> [SRU Justification]
> >>
> >> An issue was discovered in the Linux kernel before 5.11.11. The
> netfilter
> >> subsystem allows attackers to cause a denial of service (panic) because
> >> net/netfilter/x_tables.c and include/linux/netfilter/x_tables.h lack a
> >> full memory barrier upon the assignment of a new table value, aka
> >> CID-175e476b8cdf.
> >>
> >> This DOS has existed since v3.0. It was partially mitigated by
> >> cc00bcaa589914096edef7fb87ca5cee4a166b5c ("netfilter: x_tables: Switch
> >> synchronization to RCU") in v5.10, but was then reverted in v5.12
> >> which restored the
> >> full DOS vulnerability. Hence the fix commit
> >> 175e476b8cdf2a4de7432583b49c871345e4f8a1
> >> in v5.12.
> >>
> >> Focal, Hirsute, and oem-5.10 will get this patch via stable updates.
> >>
> >> [Test Plan]
> >>
> >> None
> >>
> >> [Where problems could occur]
> >
> >>
> >> At most this patch might introduce a performance reduction, though
> >> upstream testing has not been able to detect any.
> >>
> >> [Other Info]
> >
> >> Released in stable updates:
> >> linux-4.19.y
> >> linux-5.10.y
> >> linux-5.11.y
> >> linux-5.4.y
> >>
> >>
> > For Groovy I was wondering what would happen if the revert of the RCU
> > patches appears as stable patches. That patch dropped a smp_wmb() call,
> > so if the revert happens this gets re-introduced. Is there any good way
> > to prevent this?
> >
>
> We could apply (Revert "netfilter: x_tables: Switch synchronization to
> RCU") proactively before Kamal gets to it since upstream stable saw fit
> to do so for their supported kernels. Then commit
> 175e476b8cdf2a4de7432583b49c871345e4f8a1 ("netfilter: x_tables: Use
> correct memory barriers.") would likely be a clean cherry-pick.
>
> rtg
>

Yes, that ^^ is a fine plan.  If that revert is already in the tree when I
come across it in an upstream patch set, I'll simply detect it as "already
applied" and move along.

 -Kamal


>
> > For the time being:
> > Acked-by: Stefan Bader <stefan.bader at canonical.com>
> >
>
> --
> -----------
> Tim Gardner
> Canonical, Inc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210408/58b865bb/attachment.html>