linux-kernel - [RFC PATCH 0/5] mm: Fix mremap behavior when using addr hints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241210213050.2839638-1-bgeffon@google.com>
Date: Tue, 10 Dec 2024 16:30:45 -0500
From: Brian Geffon <bgeffon@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Jann Horn <jannh@...gle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, linux-mm@...ck.org, 
	Marco Vanotti <mvanotti@...gle.com>, linux-kernel@...r.kernel.org, 
	Brian Geffon <bgeffon@...gle.com>
Subject: [RFC PATCH 0/5] mm: Fix mremap behavior when using addr hints

When MREMAP_DONTUNMAP was added in e346b38 ("mm/mremap: add
MREMAP_DONTUNMAP to mremap()") we inadvertently allows for an
address hint to be specified when not using MREMAP_FIXED. This is because
mremap(2) with MREMAP_DONTUNMAP it shares a code path with MREMAP_FIXED
in mremap_to(), which means this function can be called in 3 different
scenarios: MREMAP_FIXED only, MREMAP_DONTUNMAP
only, or MREMAP_FIXED | MREMAP_DONTUNMAP. In the second case when only
MREMAP_DONTUNMAP the new_addr is passed to get_unmapped_area() which
behaves like a hint as it does with mmap(2).

Glibc now expects this behavior so it would seem it probably cannot be
removed [1]. Additionally, as Jann Horn pointed out Debian apparently
has tests for this odd undocumented behavior [2].

This series attempts to reconcile this situation.

Patch 1: Will fix the checks that should only apply to the MREMAP_FIXED
case, so that they don't apply to just MREMAP_MAYMOVE.
Patch 2: Addresses an actual bug where we can allow a hint which is
lower than the mmap_min_addr.
Patch 3: Since we're stuck with this behavior we might as well support
it for mremap(2) when MREMAP_MAYMOVE is specified.
Patch 4: Self tests for patch 1
Patch 5: Self tests for patch 3

I will mail man page updates once we finalize on the behavior for
mremap(2).

1. https://sourceware.org/git/?p=glibc.git;a=commit;h=6c40cb0e9f893d49dc7caee580a055de53562206
2. https://sources.debian.org/src/glibc/2.40-4/debian/patches/git-updates.diff/?hl=22820#L22818

Brian Geffon (5):
  mm: mremap: Fix new_addr being used as a hint with MREMAP_DONTUNMAP
  mm: mremap: Use round_hint_to_min() for new_addr hints
  mm: mremap: Allow new_addr to be specified as a hint
  selftests: mm: Add a new MREMAP_DONTUNMAP self test
  selftests: mm: Add selftest for new_addr hint with MREMAP_MAYMOVE.

 include/linux/mm_inline.h                     |  14 +++
 mm/mmap.c                                     |  13 --
 mm/mremap.c                                   |  34 ++++--
 tools/testing/selftests/mm/mremap_dontunmap.c |  41 ++++++-
 tools/testing/selftests/mm/mremap_test.c      | 113 +++++++++++++++++-
 5 files changed, 189 insertions(+), 26 deletions(-)

-- 
2.47.0.338.g60cca15819-goog