From nobody Sun Oct 5 21:45:04 2025 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A87E187FEC for ; Wed, 30 Jul 2025 00:58:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753837140; cv=none; b=L6MdqFrWkHzJCetiDhEmGVw+PQWtLlKblm3y+XKQxozpDh4Quddzf7N2H3baRKK/XXOGy3Z1iJ5nz8fUTGWD+3zg6OX4LRj8YtTrfjWItqao2KeA43aE4TcBWwRevt1jvdeRLSX+kPcHpqge82belsHx2OaksuQNOZ01cUkevN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753837140; c=relaxed/simple; bh=52dGNsfCzYMNb7XqIBXnTCNHJh+uI7s3tVSTq3e1Zzs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UM72phakmsJopk22oUX12MynuYkD86DKYEr/AmdkFz61qEkYh7zX3KLUQ2RmLJeMHeJuMarGUXTA4X6Gu78k9y+o1GlteaOkSNR8VlQJshlOp67F1lrBXHA9IimhDWp15CN9x9tuUzj07E70849MbaLGKHMkhaJZrB6JCVlPTmI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--isaacmanjarres.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Q0MaheOB; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--isaacmanjarres.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Q0MaheOB" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-31edd69d754so2918754a91.1 for ; Tue, 29 Jul 2025 17:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1753837138; x=1754441938; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jDQwseaUqKXgQMG0PL1emMIiquT/LrlyEZB+aSduFZ4=; b=Q0MaheOBcbEG6J8+lt/BqQSuEcsw7jVNhnVHmOLbnMJVHdfxQcISW1u+7F+eJCNhgm 3aWS7b2hPt0rdLxLVF/imiQdCJsBwvseeJyQzdcM1ScupDFcQPqX7hiCamVpQ3dTYrTo faQpQ+7b3M292knHogrqwwV9V4C7NApQWEOH/z2WWPSRm2Ff5pmHTYn/+QFH/3ePL0JZ Ofetf0TwdpK8CZBjtrNgIapV9o0W1p+/akoLVBwyQX1fnhgBNXRufiku3/PzfJcHlP2L CaWQwj9+mtVxlPIC3CgThVonCl6OA/YMYayOhqqoAJ/BGjoJtsTmOUVvGkfZAJLxb7tg 8t9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753837138; x=1754441938; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jDQwseaUqKXgQMG0PL1emMIiquT/LrlyEZB+aSduFZ4=; b=QoQFElWJZTZ+6xCeR2X6c75vnNzZfuxWbfrpg/f5cmgQnMl8p3fo1J0+jj5i34GUoH T3FKBMCx6OGBDp9vyUIwhOCChwP/2zYcVM2Uwl8Qmvn6s4v8VUX1MKSylTaGIouu+88n XGdSXdcDoc2J6ZKn5GIPOyFHChVPKjdDQncESrZJnlQpG9uik87w0WR6pkV+atUlEMaW f3SD1hMu5CetSFrWMLPJeC4LlhP9oWwzbOqP0O7T3vsFGUDrS/zF6FN09buEcc7xsnWW yLP46sRt6YqwYpHeI4fw7nnSxQ5r/bCM/efbP7rLWajEBr5I8/N0GuADZsGTrEHiuRpP 9iyA== X-Forwarded-Encrypted: i=1; AJvYcCW+sqxe0/Kg6UtJd+4pObmw1an2N0s7ujrTz5p5jnnyO0AR0pb0d4p1+KrdrZrpb4BSBdUm41j+AJDpImI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzyc9HvV9AUXMG0lHSA1YjMqPAjA5VU5VMC/7tIVgvKJ018PEDD Oi1jo1wxrLD9W585KvosfD/lsvZKThTq/R/4CcA8arQ1pv7ziIkFVcN13kBMM+b6sj2rKA/G3eX RqTH58Q1AUxEz2ES1U+AmfQFwrijUjzYQWLrsqA== X-Google-Smtp-Source: AGHT+IEGVoBAYELfdRdZ8xP5oRpoU0bK+jZlnzB/TmwUAobgxp21zhLfsqJQJKUf5/TTCLpNwHYxnC3kjLaDYc3GnzINcA== X-Received: from pjbpm8.prod.google.com ([2002:a17:90b:3c48:b0:31e:a865:8b32]) (user=isaacmanjarres job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4b83:b0:31c:3872:9411 with SMTP id 98e67ed59e1d1-31f5de63c28mr2092662a91.33.1753837138329; Tue, 29 Jul 2025 17:58:58 -0700 (PDT) Date: Tue, 29 Jul 2025 17:58:08 -0700 In-Reply-To: <20250730005818.2793577-1-isaacmanjarres@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250730005818.2793577-1-isaacmanjarres@google.com> X-Mailer: git-send-email 2.50.1.552.g942d659e1b-goog Message-ID: <20250730005818.2793577-4-isaacmanjarres@google.com> Subject: [PATCH 5.4.y 3/3] mm: perform the mapping_map_writable() check after call_mmap() From: "Isaac J. Manjarres" To: lorenzo.stoakes@oracle.com, gregkh@linuxfoundation.org, Muchun Song , Oscar Salvador , David Hildenbrand , Alexander Viro , Christian Brauner , Jan Kara , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kees Cook , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , "Matthew Wilcox (Oracle)" , Jann Horn , Pedro Falcato , Hugh Dickins , Baolin Wang Cc: aliceryhl@google.com, stable@vger.kernel.org, "Isaac J. Manjarres" , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Lorenzo Stoakes , Andy Lutomirski , Mike Kravetz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lorenzo Stoakes [ Upstream commit 158978945f3173b8c1a88f8c5684a629736a57ac ] In order for a F_SEAL_WRITE sealed memfd mapping to have an opportunity to clear VM_MAYWRITE, we must be able to invoke the appropriate vm_ops->mmap() handler to do so. We would otherwise fail the mapping_map_writable() check before we had the opportunity to avoid it. This patch moves this check after the call_mmap() invocation. Only memfd actively denies write access causing a potential failure here (in memfd_add_seals()), so there should be no impact on non-memfd cases. This patch makes the userland-visible change that MAP_SHARED, PROT_READ mappings of an F_SEAL_WRITE sealed memfd mapping will now succeed. There is a delicate situation with cleanup paths assuming that a writable mapping must have occurred in circumstances where it may now not have. In order to ensure we do not accidentally mark a writable file unwritable by mistake, we explicitly track whether we have a writable mapping and unmap only if we do. [lstoakes@gmail.com: do not set writable_file_mapping in inappropriate case] Link: https://lkml.kernel.org/r/c9eb4cc6-7db4-4c2b-838d-43a0b319a4f0@luci= fer.local Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D217238 Link: https://lkml.kernel.org/r/55e413d20678a1bb4c7cce889062bbb07b0df892.16= 97116581.git.lstoakes@gmail.com Signed-off-by: Lorenzo Stoakes Reviewed-by: Jan Kara Cc: Alexander Viro Cc: Andy Lutomirski Cc: Christian Brauner Cc: Hugh Dickins Cc: Matthew Wilcox (Oracle) Cc: Mike Kravetz Cc: Muchun Song Signed-off-by: Andrew Morton Cc: stable@vger.kernel.org [isaacmanjarres: added error handling to cleanup the work done by the mmap() callback and removed unused label.] Signed-off-by: Isaac J. Manjarres --- mm/mmap.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index cb712ae731cd..e591a82a26a8 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1718,6 +1718,7 @@ unsigned long mmap_region(struct file *file, unsigned= long addr, { struct mm_struct *mm =3D current->mm; struct vm_area_struct *vma, *prev; + bool writable_file_mapping =3D false; int error; struct rb_node **rb_link, *rb_parent; unsigned long charged =3D 0; @@ -1785,11 +1786,6 @@ unsigned long mmap_region(struct file *file, unsigne= d long addr, if (error) goto free_vma; } - if (is_shared_maywrite(vm_flags)) { - error =3D mapping_map_writable(file->f_mapping); - if (error) - goto allow_write_and_free_vma; - } =20 /* ->mmap() can change vma->vm_file, but must guarantee that * vma_link() below can deny write-access if VM_DENYWRITE is set @@ -1801,6 +1797,14 @@ unsigned long mmap_region(struct file *file, unsigne= d long addr, if (error) goto unmap_and_free_vma; =20 + if (vma_is_shared_maywrite(vma)) { + error =3D mapping_map_writable(file->f_mapping); + if (error) + goto close_and_free_vma; + + writable_file_mapping =3D true; + } + /* Can addr have changed?? * * Answer: Yes, several device drivers can do it in their @@ -1823,7 +1827,7 @@ unsigned long mmap_region(struct file *file, unsigned= long addr, vma_link(mm, vma, prev, rb_link, rb_parent); /* Once vma denies write, undo our temporary denial count */ if (file) { - if (is_shared_maywrite(vm_flags)) + if (writable_file_mapping) mapping_unmap_writable(file->f_mapping); if (vm_flags & VM_DENYWRITE) allow_write_access(file); @@ -1858,15 +1862,17 @@ unsigned long mmap_region(struct file *file, unsign= ed long addr, =20 return addr; =20 +close_and_free_vma: + if (vma->vm_ops && vma->vm_ops->close) + vma->vm_ops->close(vma); unmap_and_free_vma: vma->vm_file =3D NULL; fput(file); =20 /* Undo any partial mapping done by a device driver. */ unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end); - if (is_shared_maywrite(vm_flags)) + if (writable_file_mapping) mapping_unmap_writable(file->f_mapping); -allow_write_and_free_vma: if (vm_flags & VM_DENYWRITE) allow_write_access(file); free_vma: --=20 2.50.1.552.g942d659e1b-goog