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

[Tim Gardner]

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

> For the time being:
> Acked-by: Stefan Bader <stefan.bader at canonical.com>
> 

-- 
-----------
Tim Gardner
Canonical, Inc