Linux v5.4.21
This commit is contained in:
parent
afa416c6c9
commit
2809b7faa6
3 changed files with 104 additions and 2 deletions
|
|
@ -0,0 +1,95 @@
|
|||
From a34309d16f41c48ffd90e56a6f865d6a1a8c49f0 Mon Sep 17 00:00:00 2001
|
||||
From: Catalin Marinas <catalin.marinas@arm.com>
|
||||
Date: Wed, 19 Feb 2020 12:31:56 +0000
|
||||
Subject: [PATCH] mm: Avoid creating virtual address aliases in
|
||||
brk()/mmap()/mremap()
|
||||
|
||||
Currently the arm64 kernel ignores the top address byte passed to brk(),
|
||||
mmap() and mremap(). When the user is not aware of the 56-bit address
|
||||
limit or relies on the kernel to return an error, untagging such
|
||||
pointers has the potential to create address aliases in user-space.
|
||||
Passing a tagged address to munmap(), madvise() is permitted since the
|
||||
tagged pointer is expected to be inside an existing mapping.
|
||||
|
||||
The current behaviour breaks the existing glibc malloc() implementation
|
||||
which relies on brk() with an address beyond 56-bit to be rejected by
|
||||
the kernel.
|
||||
|
||||
Remove untagging in the above functions by partially reverting commit
|
||||
ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk"). In
|
||||
addition, update the arm64 tagged-address-abi.rst document accordingly.
|
||||
|
||||
Link: https://bugzilla.redhat.com/1797052
|
||||
Fixes: ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk")
|
||||
Cc: <stable@vger.kernel.org> # 5.4.x-
|
||||
Cc: Andrew Morton <akpm@linux-foundation.org>
|
||||
Cc: Florian Weimer <fweimer@redhat.com>
|
||||
Reported-by: Victor Stinner <vstinner@redhat.com>
|
||||
Acked-by: Will Deacon <will@kernel.org>
|
||||
Acked-by: Andrey Konovalov <andreyknvl@google.com>
|
||||
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
||||
---
|
||||
Documentation/arm64/tagged-address-abi.rst | 11 +++++++++--
|
||||
mm/mmap.c | 4 ----
|
||||
mm/mremap.c | 1 -
|
||||
3 files changed, 9 insertions(+), 7 deletions(-)
|
||||
|
||||
diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
|
||||
index d4a85d535bf9..f6289116893c 100644
|
||||
--- a/Documentation/arm64/tagged-address-abi.rst
|
||||
+++ b/Documentation/arm64/tagged-address-abi.rst
|
||||
@@ -44,8 +44,15 @@ The AArch64 Tagged Address ABI has two stages of relaxation depending
|
||||
how the user addresses are used by the kernel:
|
||||
|
||||
1. User addresses not accessed by the kernel but used for address space
|
||||
- management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use
|
||||
- of valid tagged pointers in this context is always allowed.
|
||||
+ management (e.g. ``mprotect()``, ``madvise()``). The use of valid
|
||||
+ tagged pointers in this context is allowed with the exception of
|
||||
+ ``brk()``, ``mmap()`` and the ``new_address`` argument to
|
||||
+ ``mremap()`` as these have the potential of aliasing with existing
|
||||
+ user addresses.
|
||||
+
|
||||
+ NOTE: This behaviour changed in v5.6 and so some earlier kernels may
|
||||
+ incorrectly accept valid tagged pointers for the ``brk()``,
|
||||
+ ``mmap()`` and ``mremap()`` system calls.
|
||||
|
||||
2. User addresses accessed by the kernel (e.g. ``write()``). This ABI
|
||||
relaxation is disabled by default and the application thread needs to
|
||||
diff --git a/mm/mmap.c b/mm/mmap.c
|
||||
index 4390dbea4aa5..514cc19c5916 100644
|
||||
--- a/mm/mmap.c
|
||||
+++ b/mm/mmap.c
|
||||
@@ -195,8 +195,6 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
|
||||
bool downgraded = false;
|
||||
LIST_HEAD(uf);
|
||||
|
||||
- brk = untagged_addr(brk);
|
||||
-
|
||||
if (down_write_killable(&mm->mmap_sem))
|
||||
return -EINTR;
|
||||
|
||||
@@ -1583,8 +1581,6 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
|
||||
struct file *file = NULL;
|
||||
unsigned long retval;
|
||||
|
||||
- addr = untagged_addr(addr);
|
||||
-
|
||||
if (!(flags & MAP_ANONYMOUS)) {
|
||||
audit_mmap_fd(fd, flags);
|
||||
file = fget(fd);
|
||||
diff --git a/mm/mremap.c b/mm/mremap.c
|
||||
index 1fc8a29fbe3f..1d98281f7204 100644
|
||||
--- a/mm/mremap.c
|
||||
+++ b/mm/mremap.c
|
||||
@@ -607,7 +607,6 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
|
||||
LIST_HEAD(uf_unmap);
|
||||
|
||||
addr = untagged_addr(addr);
|
||||
- new_addr = untagged_addr(new_addr);
|
||||
|
||||
if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
|
||||
return ret;
|
||||
--
|
||||
2.24.1
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Summary: The Linux kernel
|
|||
%if 0%{?released_kernel}
|
||||
|
||||
# Do we have a -stable update to apply?
|
||||
%define stable_update 20
|
||||
%define stable_update 21
|
||||
# Set rpm version accordingly
|
||||
%if 0%{?stable_update}
|
||||
%define stablerev %{stable_update}
|
||||
|
|
@ -559,6 +559,10 @@ Patch523: media-rc-prevent-memory-leak-in-cx23888_ir_probe.patch
|
|||
# CVE-2019-18808 rhbz 1777418 1777421
|
||||
Patch527: 0001-crypto-ccp-Release-all-allocated-memory-if-sha-type-.patch
|
||||
|
||||
# https://bugzilla.redhat.com/show_bug.cgi?id=1797052
|
||||
# http://lists.infradead.org/pipermail/linux-arm-kernel/2020-February/712003.html
|
||||
Patch528: 0001-mm-Avoid-creating-virtual-address-aliases-in-brk-mma.patch
|
||||
|
||||
# https://gitlab.freedesktop.org/drm/intel/issues/673
|
||||
Patch612: drm-i915-gt-Detect-if-we-miss-WaIdleLiteRestore.patch
|
||||
|
||||
|
|
@ -1804,6 +1808,9 @@ fi
|
|||
#
|
||||
#
|
||||
%changelog
|
||||
* Wed Feb 19 2020 Jeremy Cline <jcline@redhat.com> - 5.4.21-100
|
||||
- Linux v5.4.21
|
||||
|
||||
* Mon Feb 17 2020 Jeremy Cline <jcline@redhat.com> - 5.4.20-100
|
||||
- Linux v5.4.20
|
||||
|
||||
|
|
|
|||
2
sources
2
sources
|
|
@ -1,2 +1,2 @@
|
|||
SHA512 (linux-5.4.tar.xz) = 9f60f77e8ab972b9438ac648bed17551c8491d6585a5e85f694b2eaa4c623fbc61eb18419b2656b6795eac5deec0edaa04547fc6723fbda52256bd7f3486898f
|
||||
SHA512 (patch-5.4.20.xz) = 65fbcdbd41e35c17601ff15bbe33933be2ab7a694aa181a0b802cc11c1c653c9b688dbb382076cbad05983a0c07467955c035ae25f5175f7ce5bc24339303d77
|
||||
SHA512 (patch-5.4.21.xz) = 069daf18cb781c3ff8db4a84d71a09d8140d4182a47c384394f2d1d2c6a10df652c5c9bc2abc05aebb525b0b0baf58b0f4b044cdae279df8344ed7f250a8b0fe
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue