From patchwork Thu Feb 22 16:55:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vlastimil Babka X-Patchwork-Id: 13567606 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06F7CC54791 for ; Thu, 22 Feb 2024 16:56:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8ABC96B007B; Thu, 22 Feb 2024 11:56:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 85BAC6B007E; Thu, 22 Feb 2024 11:56:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FC096B0081; Thu, 22 Feb 2024 11:56:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5D2B26B007B for ; Thu, 22 Feb 2024 11:56:04 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0BD261A09BE for ; Thu, 22 Feb 2024 16:56:04 +0000 (UTC) X-FDA: 81820042248.20.EB8CD95 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf19.hostedemail.com (Postfix) with ESMTP id E3C141A0029 for ; Thu, 22 Feb 2024 16:56:01 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=itHBMj3O; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=C6hjy3NB; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=txCs2ZAr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gd6UBnrS; dmarc=none; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708620962; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=Id5ZCJIzCF6xRgztCP8sEZmN2Wt3QGw8Uk5BPRk8tvE=; b=tzW3jsHsetFCtmI+70pzN3VuDYKu96Lf2PT0VeiTqKKfVoZtGKUolEwzophaqfIq4nWSY8 3+uvid9FRlA5ElWtjN/hUrkOUFkzA5Cgezrc96+1wvYL0jZVYjAsoQjb5ihgZkW8623ali JSXtAHiPhuyWoyWr8DcosIaQHtBK+UY= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=itHBMj3O; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=C6hjy3NB; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=txCs2ZAr; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gd6UBnrS; dmarc=none; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708620962; a=rsa-sha256; cv=none; b=cVQo9nB4WreKZ2Zx0X5GMSsuMXl5PAkjfA1LYqp7866r74BVVArCB8cdG/v7GkenC0H8Pc 6VlolPmI+wobUfUWWdyTx+NwJCX1NVsPN0x+9BW2GduEg7QYkrnr6bDoZSe2yGBMaRd5Dh ZmEboaJD9Zko1BQls0QgvokzlUWLb0A= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id DF7541F76C; Thu, 22 Feb 2024 16:55:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708620960; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Id5ZCJIzCF6xRgztCP8sEZmN2Wt3QGw8Uk5BPRk8tvE=; b=itHBMj3OHPlkOjgvjlRSLTqGlsTJk1LHorLFB24Yuj6h7+gP1ltbkQBbslySkn9ICzJoLo CY9wxMP1z2SzYdDqp0S6WvJ8FgdImIgDPGNjorH31s6lj9jeGNwasCYZCiuLn1iKP9LrcL MBcR/tjpbnu5qBg4yLENFVH6a1v6pew= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708620960; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Id5ZCJIzCF6xRgztCP8sEZmN2Wt3QGw8Uk5BPRk8tvE=; b=C6hjy3NBXxnoVEML1w9T75bu1A41KocYG3Kx7D7iJ4vDz+m2NZDd7VthenNLvR34uaPjmj oCotSyVJcIrzvZBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708620959; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Id5ZCJIzCF6xRgztCP8sEZmN2Wt3QGw8Uk5BPRk8tvE=; b=txCs2ZAr0X6RuzONKmrg93OrNn94Zo7AaqGyovS804AiI/MCWHoQyWax45cGqo2VBhmI2q X6HrWYEto2n/wYZJE6mZNGfWz2BTFgnQpLejW3IEDlVJi95t3FclR1HHZYqljo1o8olIKU I1zEsGRhfeD80vXSANsrpD7xvCki1/A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708620959; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Id5ZCJIzCF6xRgztCP8sEZmN2Wt3QGw8Uk5BPRk8tvE=; b=gd6UBnrSH1EOBipXihpSOPeMYAtv97jOjgfXt82sz0PhaPV9WBAHfQ3YRyVEPMQLX0vHi+ DWEzYSTM4u6kyVAw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B5A80133DC; Thu, 22 Feb 2024 16:55:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Wqf6K59812XqbAAAD6G6ig (envelope-from ); Thu, 22 Feb 2024 16:55:59 +0000 From: Vlastimil Babka To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Michal Hocko , stable@vger.kernel.org Subject: [PATCH] mm, mmap: fix vma_merge() case 7 with vma_ops->close Date: Thu, 22 Feb 2024 17:55:50 +0100 Message-ID: <20240222165549.32753-2-vbabka@suse.cz> X-Mailer: git-send-email 2.43.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: E3C141A0029 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: w6rdwqaxecy6j9yu7a6s1tm4jrm6qsic X-HE-Tag: 1708620961-42077 X-HE-Meta: U2FsdGVkX18P7FF2xVA5ICN1VNe8faMw+NCsObtZIVsGBYjaZ4cDt8I1Ge6dqTJKx8JYI3ycA/NJIEfRi2LfuThOnRGFpuVR4FDQu8uKWaN2g3Y6/JmujXe2NWV9bIOjHcxhAAoEJ1Gfc7kJLoLubkzUGvlswrVkOZ49kaGNUFBhcZfoOoI4w9kGvtVXMZUGfK7bCapUFRdP37EZzJxQ7K4o0XjAdvRhx78pX1VT0GXRZlAJUf0CKBtcCZAVn/ngyQSJ0s20NXPUXdbJcr311AlYYrQiULpMKVBTClU2paczzQkVE8HuVpS9p9hktPiRlwd/68V6euW45wjmKx3+vnVM//bQQ8RbikKKJWPTlAUVDkHJYY6NfOHe93eMuETxmAOZMzZl3VNz8rcZwgcTlv2TRS0QGyfDUqc70Ym05sySLu34TtaNaBnveVr0e8GwA1crO7m07Owf1UEpEUyYX1GOrkxU5xDPVSytxZdjbXAXZdgxS+RFdsDHM1QFSYJS5pidnnC0OKBFf3/Ks2ii0Y5yBS4mi48ntZWqddietiSTj8lxM5hGPt3kpU4NIvcJujoUUzAfPgIJ3wwDz7rXp0YMoUWJpOEuybtQv92uY9vZ+cOltSqG9E/ul7fIxqxYOv3P2M2M4IYXSzrJL732zKTj1U8B1a+3C/6c49pRZ7UGFDYyZy7etZI17PRCqwyTix6hR8RMhwyP6JOXJHaoY7sirPzByGzHQHuv1uJLBXQwcgD3Ko+CdBlBtonC52o37nygow5DTa0wx/B0rBnlkg4y9LrMfpTiYQ04vKfy/YsyoSwItuxC4xKq4xZXuyU87awHsubcZL3yRw/+yS2D0wWJybcKp84uX5XZ+Cz8PmvU8Q2qggqxSB1TzdtsWpZl2JsDxngzi+3V1fFH56J+KyDImKBzwRB+KdLAaiQI5Xm0f622jmoqvbtot+LEFwEFlyjebcm7gvgcAKcO2V0 4ANowWCo Qbi3bdM0HMy01LpL6zVMlPW1XaOXTyQkFf+CtTX7FPcCrAryeZjYJfsn+BMvAI75MtnKy3mvZGbtHR5DwwuQizd74k6f8VgZd5MKO3WicUX3LqyI4wJeFwx4Alj3vyzuEz+ZzsiZN77yWH0ik2f3FFH5Cwd2p5b2EIozVY2GO8cmuwH9YyDhyJ/SqBUyvBBEwiTG0SFGVgCHGUV8BGulhzlnfIjo/y/SK1/rlJNOZCDlPiP554IxE9lhqLKjoWcY0/eO3Q8byE5i6ZhVqnqDzNjXoGfDEx+9Tfs8DtOCEutQGZfhKFmfFybtfmJnlcRYeD4sft+xBrhCF2UxjtwtWwDPZ/y8tC4QqQbI9MYvNnxs3IqmcN7P5G0oK/qnGaubdIKrO X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: When debugging issues with a workload using SysV shmem, Michal Hocko has come up with a reproducer that shows how a series of mprotect() operations can result in an elevated shm_nattch and thus leak of the resource. The problem is caused by wrong assumptions in vma_merge() commit 714965ca8252 ("mm/mmap: start distinguishing if vma can be removed in mergeability test"). The shmem vmas have a vma_ops->close callback that decrements shm_nattch, and we remove the vma without calling it. vma_merge() has thus historically avoided merging vma's with vma_ops->close and commit 714965ca8252 was supposed to keep it that way. It relaxed the checks for vma_ops->close in can_vma_merge_after() assuming that it is never called on a vma that would be a candidate for removal. However, the vma_merge() code does also use the result of this check in the decision to remove a different vma in the merge case 7. A robust solution would be to refactor vma_merge() code in a way that the vma_ops->close check is only done for vma's that are actually going to be removed, and not as part of the preliminary checks. That would both solve the existing bug, and also allow additional merges that the checks currently prevent unnecessarily in some cases. However to fix the existing bug first with a minimized risk, and for easier stable backports, this patch only adds a vma_ops->close check to the buggy case 7 specifically. All other cases of vma removal are covered by the can_vma_merge_before() check that includes the test for vma_ops->close. The reproducer code, adapted from Michal Hocko's code: int main(int argc, char *argv[]) { int segment_id; size_t segment_size = 20 * PAGE_SIZE; char * sh_mem; struct shmid_ds shmid_ds; key_t key = 0x1234; segment_id = shmget(key, segment_size, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR); sh_mem = (char *)shmat(segment_id, NULL, 0); mprotect(sh_mem + 2*PAGE_SIZE, PAGE_SIZE, PROT_NONE); mprotect(sh_mem + PAGE_SIZE, PAGE_SIZE, PROT_WRITE); mprotect(sh_mem + 2*PAGE_SIZE, PAGE_SIZE, PROT_WRITE); shmdt(sh_mem); shmctl(segment_id, IPC_STAT, &shmid_ds); printf("nattch after shmdt(): %lu (expected: 0)\n", shmid_ds.shm_nattch); if (shmctl(segment_id, IPC_RMID, 0)) printf("IPCRM failed %d\n", errno); return (shmid_ds.shm_nattch) ? 1 : 0; } Fixes: 714965ca8252 ("mm/mmap: start distinguishing if vma can be removed in mergeability test") Reported-by: Michal Hocko Cc: Signed-off-by: Vlastimil Babka --- mm/mmap.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index d89770eaab6b..a4238373ee9b 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -954,10 +954,19 @@ static struct vm_area_struct } else if (merge_prev) { /* case 2 */ if (curr) { vma_start_write(curr); - err = dup_anon_vma(prev, curr, &anon_dup); if (end == curr->vm_end) { /* case 7 */ + /* + * can_vma_merge_after() assumed we would not be + * removing prev vma, so it skipped the check + * for vm_ops->close, but we are removing curr + */ + if (curr->vm_ops && curr->vm_ops->close) + err = -EINVAL; + else + err = dup_anon_vma(prev, curr, &anon_dup); remove = curr; } else { /* case 5 */ + err = dup_anon_vma(prev, curr, &anon_dup); adjust = curr; adj_start = (end - curr->vm_start); }