linux-kernel - [PATCH v2 2/3] mm: lock newly mapped VMA which can be modified after it becomes visible

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230708191212.4147700-2-surenb@google.com>
Date:   Sat,  8 Jul 2023 12:12:11 -0700
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     torvalds@...ux-foundation.org
Cc:     akpm@...ux-foundation.org, regressions@...mhuis.info,
        bagasdotme@...il.com, jacobly.alt@...il.com, willy@...radead.org,
        liam.howlett@...cle.com, david@...hat.com, peterx@...hat.com,
        ldufour@...ux.ibm.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org,
        linux-arm-kernel@...ts.infradead.org, gregkh@...uxfoundation.org,
        regressions@...ts.linux.dev,
        Suren Baghdasaryan <surenb@...gle.com>, stable@...r.kernel.org
Subject: [PATCH v2 2/3] mm: lock newly mapped VMA which can be modified after
 it becomes visible

mmap_region adds a newly created VMA into VMA tree and might modify it
afterwards before dropping the mmap_lock. This poses a problem for page
faults handled under per-VMA locks because they don't take the mmap_lock
and can stumble on this VMA while it's still being modified. Currently
this does not pose a problem since post-addition modifications are done
only for file-backed VMAs, which are not handled under per-VMA lock.
However, once support for handling file-backed page faults with per-VMA
locks is added, this will become a race.
Fix this by write-locking the VMA before inserting it into the VMA tree.
Other places where a new VMA is added into VMA tree do not modify it
after the insertion, so do not need the same locking.

Cc: stable@...r.kernel.org
Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
---
 mm/mmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index c66e4622a557..84c71431a527 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2812,6 +2812,8 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 	if (vma->vm_file)
 		i_mmap_lock_write(vma->vm_file->f_mapping);

+	/* Lock the VMA since it is modified after insertion into VMA tree */
+	vma_start_write(vma);
 	vma_iter_store(&vmi, vma);
 	mm->map_count++;
 	if (vma->vm_file) {
-- 
2.41.0.390.g38632f3daf-goog