linux-kernel - [PATCH mm-unstable] mm/madvise: handle MADV_{HWPOISON,SOFT_OFFLINE} from madvise

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: <20250211063201.5106-1-sj@kernel.org>
Date: Mon, 10 Feb 2025 22:32:01 -0800
From: SeongJae Park <sj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: SeongJae Park <sj@...nel.org>,
	"Liam R. Howlett" <howlett@...il.com>,
	Davidlohr Bueso <dave@...olabs.net>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	"Lai, Yi" <yi1.lai@...ux.intel.com>
Subject: [PATCH mm-unstable] mm/madvise: handle MADV_{HWPOISON,SOFT_OFFLINE} from madvise_unlock()

madvise_lock() does nothing for MADV_HWPOSION and MADV_SOFT_OFFLINE
behavior, but madvise_unlock() does mmap_lock unlocking regardless of
the behavior.  Commit 948a0a9ea070 ("mm/madvise: split out mmap locking
operations for madvise()") in mm-unstable, which introduced the wrong
function didn't cause a real problem because do_madvise() was not
calling madvise_unlock() for the behavior.

Later, commit f19c9d7b57cf ("mm/madvise: split out madvise() behavior
execution") in mm-unstable made do_madvise() to call madvise_unlock()
even for the two behaviors.  As a result, the kernel tries to unlock
unlocked mmap_lock.

Fix the issue by handling the two behaviors in madvise_unlock().  For
the two behaviors, do nothing but just return.  Also remove an
unnecessary blank line in madvise_lock().

Technically speaking this patch fixes commit f19c9d7b57cf ("mm/madvise:
split out madvise() behavior execution").  But since the broken commit
is not in the mainline yet, squashing this fix into commit 948a0a9ea070
("mm/madvise: split out mmap locking operations for madvise()") would
make more sense, so adding Fixes: tag with it.

Fixes: 948a0a9ea070 ("mm/madvise: split out mmap locking operations for madvise()") # mm-unstable
Reported-by: "Lai, Yi" <yi1.lai@...ux.intel.com>
Closes: https://lore.kernel.org/Z6rgiVp7221r4JZ5@ly-workstation
Signed-off-by: SeongJae Park <sj@...nel.org>
---
 mm/madvise.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index b5ef8e03d8b0..b8969457f3ef 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1577,7 +1577,6 @@ int madvise_set_anon_name(struct mm_struct *mm, unsigned long start,

 static int madvise_lock(struct mm_struct *mm, int behavior)
 {
-
 #ifdef CONFIG_MEMORY_FAILURE
 	if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
 		return 0;
@@ -1595,6 +1594,11 @@ static int madvise_lock(struct mm_struct *mm, int behavior)

 static void madvise_unlock(struct mm_struct *mm, int behavior)
 {
+#ifdef CONFIG_MEMORY_FAILURE
+	if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
+		return;
+#endif
+
 	if (madvise_need_mmap_write(behavior))
 		mmap_write_unlock(mm);
 	else

base-commit: 8bf30f9d23eb5040d37e6e712789cee8e71e1577
-- 
2.39.5