APPLIED [OEM-5.10] Re: [PATCH 0/10 v4][B/F/F:OEM-5.6/F:OEM-5.10/G] CVE-2021-29650 xtables membarrier DoS

[Timo Aaltonen]

On 20.4.2021 12.39, Timo Aaltonen wrote:
> On 9.4.2021 17.03, Tim Gardner wrote:
>> v2 - Update Groovy patches. Add Focal, OEM-5.10
>> v3 - Embed release name in patch subject.
>> v4 - added an additional revert related to RCU in Focal+
>>
>> [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, Groovy, OEM-5.6, amd OEM-5.10 required 2 reverts in order to 
>> cleanly apply
>> "netfilter: x_tables: Use correct memory barriers." and correctly 
>> implement the code.
>>
>> [Test Plan]
>> None - this one is quite difficult to reproduce. It was tested on a 4 
>> core MIPS.
>>
>> [Where problems could occur]
>> Removing the RCU code may restore races that existed prior. Hopefully
>> the full memory barriers are the correct fix.
>> At most this patch might introduce a performance reduction, though
>> upstream testing has not been able to detect any. Upstream seems
>> confident that reverting the RCU patch and applying the write barrier
>> patch was the right thing to do.
>>
>> [Other Info]
>> Hirsute already has these patches via stable.
>>
>>
>>
>>
> 
> OEM-5.10 received this via v5.10.27
> 
> 


-- 
t