NetBSD Problem Report #56911

From www@netbsd.org  Mon Jul  4 16:21:51 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4AD151A921F
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  4 Jul 2022 16:21:51 +0000 (UTC)
Message-Id: <20220704162149.B1EB21A9239@mollari.NetBSD.org>
Date: Mon,  4 Jul 2022 16:21:49 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: uvm_vslock fails to block munmap
X-Send-Pr-Version: www-1.0

>Number:         56911
>Category:       kern
>Synopsis:       uvm_vslock fails to block munmap
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 04 16:25:00 +0000 2022
>Originator:     Taylor R Campbell
>Release:        NetBSD-current
>Organization:
Th NtBSD Fndtn
>Environment:
ruled unconstitutional by SCOTUS, 6-3
>Description:
Some kernel systems -- such as genfs_directio, mincore(2), and MI _ucas_32/_ucas_64 -- rely on uvm_vslock to lock virtual address mappings to physical pages, so that, e.g., pmap_extract will succeed:

https://nxr.netbsd.org/xref/src/sys/miscfs/genfs/genfs_io.c?r=1.102#1916

uvm_vslock does prevent the pages from being swapped.  However, it does not prevent concurrent munmap(2) from unmapping them, or concurrent mremap(2) from remapping them.
>How-To-Repeat:
munmap (or mmap, or mremap) a virtual address range concurrently with a read/write on a file opened O_DIRECT, or concurrently with mincore(2), or concurrently with futex(2).

Example crashes with reproducer: https://syzkaller.appspot.com/bug?id=f82f8fba49a7138ffc83001e6ca9a19d6d9c4955
>Fix:
Yes please!

mmap/munmap/mremap must block until the virtual address range in question is released by uvm_vsunlock.  This should be a reasonably short duration -- unless uvm_vslock is blocking waiting for swapping -- because once the pages are locked no more I/O should be happening.

Home	PR Database Search