[SRU Bionic 0/3] CVE-2021-4002

[Thadeu Lima de Souza Cascardo]

https://www.openwall.com/lists/oss-security/2021/11/25/1

[Impact]
Missing TLB flush on hugetlb unmapping may allow a different process to
access another process memory, as long as it is using hugetlb mappings.

[Test case]
POC from the link above was used to test it on amd64 and arm64.

[Potential regression]
hugetlb users may regress. arm64 could fail to boot or even crash.

[Backport]
The tip was picked up from 4.19.y queue when it was first submitted, but it
failed to build on arm64. Upstream reverted it because of that failure. Doing
some quick work, I found out the missing commits.

As s390x failed to build with a different backport, I investigated the many
differences in its TLB MMU Gather API implementation, but it turns out that the
changed path is only trigerred when huge_pmd_unshare returns non-0. And that
only happens on architectures where CONFIG_ARCH_WANT_HUGE_PMD_SHARE is defined.
And that is only on x86, arm64 and riscv.

We don't support riscv on 4.15 and the other two arches had that path tested
with the POC.

[Tests]
The POC fails on amd64 with 4.15. It was still used to exercise the changed
path on amd64.

On arm64, the POC works and the applied commits make it fail as expected.


Nadav Amit (1):
  hugetlbfs: flush TLBs correctly after huge_pmd_unshare

Nicholas Piggin (1):
  mm: mmu_notifier fix for tlb_end_vma

Will Deacon (1):
  arm64: tlb: Provide forward declaration of tlb_flush() before
    including tlb.h

 arch/arm/include/asm/tlb.h   |  8 ++++++++
 arch/arm64/include/asm/tlb.h |  2 ++
 arch/ia64/include/asm/tlb.h  | 10 ++++++++++
 arch/s390/include/asm/tlb.h  | 16 ++++++++++++++++
 arch/sh/include/asm/tlb.h    |  9 +++++++++
 arch/um/include/asm/tlb.h    | 12 ++++++++++++
 include/asm-generic/tlb.h    | 19 +++++++++++++++----
 mm/hugetlb.c                 | 19 +++++++++++++++++++
 mm/memory.c                  | 20 ++++++++++----------
 9 files changed, 101 insertions(+), 14 deletions(-)

-- 
2.32.0