Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp9919500rwl; Wed, 11 Jan 2023 11:50:00 -0800 (PST) X-Google-Smtp-Source: AMrXdXv3VC3Rx87qQw/uTZTzf/NfUG3+RON9XPpI+LMLu7xKLB0/H8MxTL1dZ2SnOtS8MLaPm2ia X-Received: by 2002:a17:907:a789:b0:7c0:bbab:22e5 with SMTP id vx9-20020a170907a78900b007c0bbab22e5mr67142762ejc.16.1673466600612; Wed, 11 Jan 2023 11:50:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673466600; cv=none; d=google.com; s=arc-20160816; b=TcyQynVNfnFqDONBvt91bI7fkwrIhw+e5PBW0k4nImHj4f11ask54DFH4MrNlHE7ie FjvDHxF6fVIfvPAmucZhwXapUHSZy9T1SsvIcz0LOFhSyVIk5Ew3QgLGom05F18K5Ye9 2KkJYq/8WupU39IKFdsE0VQ5OEZ4U48w3r3u+lqKXGLI/hHyTbnj1jBwQIho3VlRSITA X9KUHjWUZ+vkXm4GERK/R8JLFn0rgJ4o2QBdW27RYvn2aA4j5XHOY17YiCKV+O4JW9MQ +xTYeo2IPsMXwP/aNAQYBMcUPYaJnH1KCrb1vvxLiQlq7GrX5yLYt7akLAig2rxhk6u3 E4lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature; bh=Mbvcywh2c3HfOh904vLvZFGHnaoqFL7ia6UfCCLzqBY=; b=rc1bP2X0R0NRcdr31+PAInDvM6tNNHepBjZlBpf7IZKpdimoZ6u9dEtV7zJj9rV2lm aKBMXbp1Sa9jEjHHk5lqD+LQgRu+C8yAkvtQAYBCBhDKVBvl+qAlxrQLQS2bPv+sRMHb kHi3ACkFRgb++7SAxOLOgybPCKCabD+24aQ39m7ys66wYTjp8MdWDPAqL9ndqJU9UTIt ZFdoPkiNxjbRFHblfN0iyzhJ07Y7MYfjF02k77JUJmW5MCYakdWNrK63g58YAx5E0CTD F4yqf03DhhAJH/ag5u9lTCgO1LRVkTwVEJpIQFCrScXxWHYJZHHYKyrXfMV6IHCd7lJX sNzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=esjjql4t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hp16-20020a1709073e1000b0084d2239b497si16578769ejc.192.2023.01.11.11.49.47; Wed, 11 Jan 2023 11:50:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=esjjql4t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231732AbjAKThq (ORCPT + 53 others); Wed, 11 Jan 2023 14:37:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231831AbjAKTho (ORCPT ); Wed, 11 Jan 2023 14:37:44 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1C44261D for ; Wed, 11 Jan 2023 11:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673465821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Mbvcywh2c3HfOh904vLvZFGHnaoqFL7ia6UfCCLzqBY=; b=esjjql4tmEj8tJt9K4Z51Q5Gi3zpV8bkLWpSIGMmKy4XiRG+UmrZUG8Kji5f47kodmOl/8 s09lE3c3j7ZJLuPSXRTOj5mLOEPMKU/Ria92uW6HUf628kBD7uIjUL6vkFr0rIEDV8P4zV W3P3b7F8qfnfJRlu53NGaH4EbIlnzvs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-595--m7sSMw6Ny66ClXGMpAN-g-1; Wed, 11 Jan 2023 14:36:55 -0500 X-MC-Unique: -m7sSMw6Ny66ClXGMpAN-g-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4118C101A52E; Wed, 11 Jan 2023 19:36:55 +0000 (UTC) Received: from segfault.boston.devel.redhat.com (segfault.boston.devel.redhat.com [10.19.60.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EE47F1121314; Wed, 11 Jan 2023 19:36:54 +0000 (UTC) From: Jeff Moyer To: Seth Jenkins Cc: Alexander Viro , Benjamin LaHaise , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-kernel@vger.kernel.org, Jann Horn , Pavel Emelyanov , stable@vger.kernel.org, Andrew Morton Subject: Re: [PATCH] aio: fix mremap after fork null-deref References: <20221104212519.538108-1-sethjenkins@google.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 Date: Wed, 11 Jan 2023 14:40:51 -0500 In-Reply-To: <20221104212519.538108-1-sethjenkins@google.com> (Seth Jenkins's message of "Fri, 4 Nov 2022 17:25:19 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Seth, Seth Jenkins writes: > Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced > a null-deref if mremap is called on an old aio mapping after fork as > mm->ioctx_table will be set to NULL. > > Fixes: e4a0d3e720e7 ("aio: Make it possible to remap aio ring") > Cc: stable@vger.kernel.org > Signed-off-by: Seth Jenkins > --- > fs/aio.c | 20 +++++++++++--------- > 1 file changed, 11 insertions(+), 9 deletions(-) > > diff --git a/fs/aio.c b/fs/aio.c > index 5b2ff20ad322..74eae7de7323 100644 > --- a/fs/aio.c > +++ b/fs/aio.c > @@ -361,16 +361,18 @@ static int aio_ring_mremap(struct vm_area_struct *vma) > spin_lock(&mm->ioctx_lock); > rcu_read_lock(); > table = rcu_dereference(mm->ioctx_table); > - for (i = 0; i < table->nr; i++) { > - struct kioctx *ctx; > - > - ctx = rcu_dereference(table->table[i]); > - if (ctx && ctx->aio_ring_file == file) { > - if (!atomic_read(&ctx->dead)) { > - ctx->user_id = ctx->mmap_base = vma->vm_start; > - res = 0; > + if (table) { > + for (i = 0; i < table->nr; i++) { > + struct kioctx *ctx; > + > + ctx = rcu_dereference(table->table[i]); > + if (ctx && ctx->aio_ring_file == file) { > + if (!atomic_read(&ctx->dead)) { > + ctx->user_id = ctx->mmap_base = vma->vm_start; > + res = 0; > + } > + break; > } > - break; > } > } I wonder if it would be better to not copy the ring mapping on fork. Something like the below? I think that would be more in line with expectations (the ring isn't available in the child process). -Jeff diff --git a/fs/aio.c b/fs/aio.c index 562916d85cba..dbf3b0749cb4 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -390,7 +390,7 @@ static const struct vm_operations_struct aio_ring_vm_ops = { static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma) { - vma->vm_flags |= VM_DONTEXPAND; + vma->vm_flags |= VM_DONTEXPAND|VM_DONTCOPY; vma->vm_ops = &aio_ring_vm_ops; return 0; }