| Message ID | 20210409140321.7279-1-tim.gardner@canonical.com |
|---|---|
| Headers | show |
| Series | CVE-2021-29650 xtables membarrier DoS | expand |
On 09.04.21 16: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. > > > > Acked-by: Stefan Bader <stefan.bader@canonical.com>
On 09/04/2021 15: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. > > Thanks Tim, looks fine to me. Acked-by: Colin Ian King <colin.king@canonical.com>
On 09.04.21 16: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. > > > > Applied to bionic:linux, focal:linux and groovy:linux. Thanks, Kleber
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
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 > >
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.