From mboxrd@z Thu Jan 1 00:00:00 1970 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 BA5B3CF9C6B for ; Tue, 24 Sep 2024 21:47:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B6936B00A4; Tue, 24 Sep 2024 17:47:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4674B6B00A6; Tue, 24 Sep 2024 17:47:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 308176B00A7; Tue, 24 Sep 2024 17:47:41 -0400 (EDT) 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 13F476B00A4 for ; Tue, 24 Sep 2024 17:47:41 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B07121C5488 for ; Tue, 24 Sep 2024 21:47:40 +0000 (UTC) X-FDA: 82600969080.18.99C0296 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id CFE79180013 for ; Tue, 24 Sep 2024 21:47:37 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Nf9b+eB0; spf=pass (imf16.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727214397; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jUJ0vrx87M3w3+0vUJFMFBHdvfV1NNHDLDEL89XUivk=; b=iDFSX98DH6H/uDJnu/JzRGJsON/FPslrLgybq7HM7CDTBrwOkdXxShsVf7ZbX2nq/Ra7iY rgMxqP/eFeoHNBLbqqJGiw74B+SlwlS8yIjLPlRSFVKedrMHzr038n6Wi74EICULCO7xT1 UufLW7iw49at8z8WihbyPrZXxjfnzpM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Nf9b+eB0; spf=pass (imf16.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727214397; a=rsa-sha256; cv=none; b=XrIW8iY7mobE2ars0VYsz83h8xyKmyUZbTQFLbk8fQSzU1KD5UCDaSNymPty+jLMTlwsyt 6s4U7kGDbiPNM/AgltiC1CRU1s3dWvCSwNtZz+gm3wvWPVqer13fGbEJw8i4iIThskas5O mRNJJPKFGe4o41p8M7lLDLm1/cPjBgY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727214457; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jUJ0vrx87M3w3+0vUJFMFBHdvfV1NNHDLDEL89XUivk=; b=Nf9b+eB02b1y1Kad1avE4OunWZFpLOg1NokiWTivuZr22v03Dwqu1OpJUCyxopmUk8jaHl JvGspcQKFiogl7zmwCRF7+rSEoDv5B0f/pDGs2tuujypHoxztswUFT4qSMvmTDe0crC1TO hCBiW4zELE1rYHOy1AWG92ZTTtG5mEA= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-a7Sys6XcOP6TOETi1aI9Qg-1; Tue, 24 Sep 2024 17:47:35 -0400 X-MC-Unique: a7Sys6XcOP6TOETi1aI9Qg-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (unknown [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 78D3A18B651B; Tue, 24 Sep 2024 21:47:34 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.145]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 14CCA1956088; Tue, 24 Sep 2024 21:47:31 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <202409131438.3f225fbf-oliver.sang@intel.com> References: <202409131438.3f225fbf-oliver.sang@intel.com> To: kernel test robot Cc: dhowells@redhat.com, oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , Christian Brauner , Jeff Layton , netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org Subject: Re: [linux-next:master] [netfs] a05b682d49: BUG:KASAN:slab-use-after-free_in_copy_from_iter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1191932.1727214450.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Sep 2024 22:47:30 +0100 Message-ID: <1191933.1727214450@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: CFE79180013 X-Stat-Signature: bc8s7oxnqrg4tp6te65p545x7y8hkgyd X-HE-Tag: 1727214457-395317 X-HE-Meta: U2FsdGVkX1/FGZ50uapu9uSNuQ/W2wKTMmXwMVhE/ihbXEPIEltZHgiYLj7wPOmq2QZ/43IvFXtd6HpifmHGJH/yNpWkzAdK6veu3ibJAVyiRbHQAn+6MolP0osYRBU/1YyAmOwbO8zpD1QEIUAoVSQTgt1adD1xcFXSRJlNFv5ysY0J3R/Qw6cukaMxVCc7V3mkTJw3rKESftohwXEPYZYnCO6yZPgZKMMhMnz6EWE4TI8BifD8Dtg2FxmelLyJr41qbqnWRkrn82GxXlYOM2zNOVM2Vkg+EDmx/N2pVxOkXnZ7HIqA67xKzztBwGVPe699mvi2dI03OsKt4zonOyNgxJxIC5ffqDaBbsJL8o1ec2UsewHeGup2x8m102fPUoqdHpntDD2FZLhNuyp+gyepeTCy9SxBmSp/6H5+UerIYXhSReLuXuKc9xgA3uH1ENyuUhSl3/8DglxEZjeVMAaxzdxm+d6/fyLp7/kaluI4ICK1wyk1rPPjqParPQcZPvgsvoD2MnM0U950ZQGsDaTzmYRFjc700S/PdtJGxtRZbGam+CsTo/05ei5uUYjObrDoZ3mmz8Qi8sLUYVC2bDbeE87Qd84sw+XGG3+1t6FB7j3gn+7Il/yGjsvegC7lmv7iYk7qDzB+ASiXRWFcdrYZ94GCs3cZlNfF2TUmq9X/GmWRLr5RMWexZfyAsz1VlO5l2M0PQDJ1oACIWW5YIFqx0RcbrqLT8qPm27BMQiuNnnNTgMXQ6vJnLU4zRH7yh/N/HGpmNGI8JQgSwAKZ6N58OcFehj8yXDHBa8sw4KD5AKp2R0c9Lzvvz7g1mPayUmTdQWfYBsm1/Rq0C7xuKyypeK2qNRJhUBaVdszIFn46pSycaSynHt4lWyFthDUWT4Ss7MUFMYmvWeGt01/mHc++8cbhRnaz8L+IeUOhYqp3eUzTczJRO3sjust9s1P1St6l0Br/jRzjPVPyuec Ysy468F6 j0JDz/HpPgHVc3EfVXv3SlKFNxkO4x9cvQT9divW7ltOWRb4DTFT3mRRYXZSaXEbWQwoK0S2K9/92o4VJGU22pyL9p3uJBwj8W5Duwmtc4wvRhytyLo1rFxMlURRV5VnlhS2N7aPVVvZaobhkOzud3Nk8VRWvY7O1YCKMol51O+ww5GWQaQEu6YvU+woxh8/DPEnIGWZo6IjRyFbwgXpSHdKxfuH7NcbMPBrFLtLdS39UBybilJX7URTeveFd6L0Hcm1OmPZSjq7h0HtC6k8vz6P25nAHaqZIzisQvkYcHNjgLxXHtIp+bqiUtdYUlZvbn5hb2mecwCCsE8QXcz0ItvrC5Bn0fH50TaYoolbUABCkf8mfnu8+NVc4k3Qr8fFiRIafkDcFGZ4s2xPz8IFhoLKsX8C+yRkCQN/wRXgXexBkBGHMm+OPq6+AVPKgg1c+FmizKqsj8V034OwGuK8cp4kGjIuahOTOOPcLSQxK3ml3VoppGorgDBkICEo4WONTBCiiqZ7utOwJ9mTAu2iwCbycjcYTHiNjuaRmLG3M8G+2AltLa9LkOMiIOE8fy0fgWrd6Wh8yU8YzepWrR/j3Vh+92nB0X/ae9SQERt14zbchYTu5ZK01dVLO0tsiL973vyuW8lNKYmGYFE+6MUFwVl3dl65p42lYi1XutnEK2opF8IUz3rqkdU0AnbAz3xIsqVqZpUKSeCHTwzdWom4A9Nom+A== 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: Does the attached fix the problem? David --- netfs: Fix write oops in generic/346 (9p) and maybe generic/074 (cifs) In netfslib, a buffered writeback operation has a 'write queue' of folios that are being written, held in a linear sequence of folio_queue structs. The 'issuer' adds new folio_queues on the leading edge of the queue and populates each one progressively; the 'collector' pops them off the trailing edge and discards them and the folios they point to as they are consumed. The queue is required to always retain at least one folio_queue structure. This allows the queue to be accessed without locking and with just a bit o= f barriering. When a new subrequest is prepared, its ->io_iter iterator is pointed at th= e current end of the write queue and then the iterator is extended as more data is added to the queue until the subrequest is committed. Now, the problem is that the folio_queue at the leading edge of the write queue when a subrequest is prepared might have been entirely consumed - bu= t not yet removed from the queue as it is the only remaining one and is preventing the queue from collapsing. So, what happens is that subreq->io_iter is pointed at the spent folio_queue, then a new folio_queue is added, and, at that point, the collector is at entirely at liberty to immediately delete the spent folio_queue. This leaves the subreq->io_iter pointing at a freed object. If the system is lucky, iterate_folioq() sees ->io_iter, sees the as-yet uncorrupted freed object and advances to the next folio_queue in the queue. In the case seen, however, the freed object gets recycled and put back ont= o the queue at the tail and filled to the end. This confuses iterate_folioq() and it tries to step ->next, which may be NULL - resultin= g in an oops. Fix this by the following means: (1) When preparing a write subrequest, make sure there's a folio_queue struct with space in it at the leading edge of the queue. A function to make space is split out of the function to append a folio so that it can be called for this purpose. (2) If the request struct iterator is pointing to a completely spent folio_queue when we make space, then advance the iterator to the newl= y allocated folio_queue. The subrequest's iterator will then be set from this. Whilst we're at it, also split out the function to allocate a folio_queue, initialise it and do the accounting. The oops could be triggered using the generic/346 xfstest with a filesyste= m on9P over TCP with cache=3Dloose. The oops looked something like: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page ... RIP: 0010:_copy_from_iter+0x2db/0x530 ... Call Trace: ... p9pdu_vwritef+0x3d8/0x5d0 p9_client_prepare_req+0xa8/0x140 p9_client_rpc+0x81/0x280 p9_client_write+0xcf/0x1c0 v9fs_issue_write+0x87/0xc0 netfs_advance_write+0xa0/0xb0 netfs_write_folio.isra.0+0x42d/0x500 netfs_writepages+0x15a/0x1f0 do_writepages+0xd1/0x220 filemap_fdatawrite_wbc+0x5c/0x80 v9fs_mmap_vm_close+0x7d/0xb0 remove_vma+0x35/0x70 vms_complete_munmap_vmas+0x11a/0x170 do_vmi_align_munmap+0x17d/0x1c0 do_vmi_munmap+0x13e/0x150 __vm_munmap+0x92/0xd0 __x64_sys_munmap+0x17/0x20 do_syscall_64+0x80/0xe0 entry_SYSCALL_64_after_hwframe+0x71/0x79 This may also fix a similar-looking issue with cifs and generic/074. | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-lkp/202409180928.f20b5a08-oliver.sa= ng@intel.com Signed-off-by: David Howells cc: Eric Van Hensbergen cc: Latchesar Ionkov cc: Dominique Martinet cc: Christian Schoenebeck cc: Steve French cc: Paulo Alcantara cc: Jeff Layton cc: v9fs@lists.linux.dev cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org --- fs/netfs/internal.h | 2 + fs/netfs/misc.c | 72 ++++++++++++++++++++++++++++++++++---------= ------ fs/netfs/objects.c | 12 ++++++++ fs/netfs/write_issue.c | 12 +++++++- 4 files changed, 76 insertions(+), 22 deletions(-) diff --git a/fs/netfs/internal.h b/fs/netfs/internal.h index c7f23dd3556a..79c0ad89affb 100644 --- a/fs/netfs/internal.h +++ b/fs/netfs/internal.h @@ -58,6 +58,7 @@ static inline void netfs_proc_del_rreq(struct netfs_io_r= equest *rreq) {} /* * misc.c */ +struct folio_queue *netfs_buffer_make_space(struct netfs_io_request *rreq= ); int netfs_buffer_append_folio(struct netfs_io_request *rreq, struct folio= *folio, bool needs_put); struct folio_queue *netfs_delete_buffer_head(struct netfs_io_request *wre= q); @@ -76,6 +77,7 @@ void netfs_clear_subrequests(struct netfs_io_request *rr= eq, bool was_async); void netfs_put_request(struct netfs_io_request *rreq, bool was_async, enum netfs_rreq_ref_trace what); struct netfs_io_subrequest *netfs_alloc_subrequest(struct netfs_io_reques= t *rreq); +struct folio_queue *netfs_folioq_alloc(struct netfs_io_request *rreq, gfp= _t gfp); = static inline void netfs_see_request(struct netfs_io_request *rreq, enum netfs_rreq_ref_trace what) diff --git a/fs/netfs/misc.c b/fs/netfs/misc.c index 0ad0982ce0e2..a743e8963247 100644 --- a/fs/netfs/misc.c +++ b/fs/netfs/misc.c @@ -9,34 +9,64 @@ #include "internal.h" = /* - * Append a folio to the rolling queue. + * Make sure there's space in the rolling queue. */ -int netfs_buffer_append_folio(struct netfs_io_request *rreq, struct folio= *folio, - bool needs_put) +struct folio_queue *netfs_buffer_make_space(struct netfs_io_request *rreq= ) { - struct folio_queue *tail =3D rreq->buffer_tail; - unsigned int slot, order =3D folio_order(folio); + struct folio_queue *tail =3D rreq->buffer_tail, *prev; + unsigned int prev_nr_slots =3D 0; = if (WARN_ON_ONCE(!rreq->buffer && tail) || WARN_ON_ONCE(rreq->buffer && !tail)) - return -EIO; - - if (!tail || folioq_full(tail)) { - tail =3D kmalloc(sizeof(*tail), GFP_NOFS); - if (!tail) - return -ENOMEM; - netfs_stat(&netfs_n_folioq); - folioq_init(tail); - tail->prev =3D rreq->buffer_tail; - if (tail->prev) - tail->prev->next =3D tail; - rreq->buffer_tail =3D tail; - if (!rreq->buffer) { - rreq->buffer =3D tail; - iov_iter_folio_queue(&rreq->io_iter, ITER_SOURCE, tail, 0, 0, 0); + return ERR_PTR(-EIO); + + prev =3D tail; + if (prev) { + if (!folioq_full(tail)) + return tail; + prev_nr_slots =3D folioq_nr_slots(tail); + } + + tail =3D netfs_folioq_alloc(rreq, GFP_NOFS); + if (!tail) + return ERR_PTR(-ENOMEM); + tail->prev =3D prev; + if (prev) + /* [!] NOTE: After we set prev->next, the consumer is entirely + * at liberty to delete prev. + */ + WRITE_ONCE(prev->next, tail); + + rreq->buffer_tail =3D tail; + if (!rreq->buffer) { + rreq->buffer =3D tail; + iov_iter_folio_queue(&rreq->io_iter, ITER_SOURCE, tail, 0, 0, 0); + } else { + /* Make sure we don't leave the master iterator pointing to a + * block that might get immediately consumed. + */ + if (rreq->io_iter.folioq =3D=3D prev && + rreq->io_iter.folioq_slot =3D=3D prev_nr_slots) { + rreq->io_iter.folioq =3D tail; + rreq->io_iter.folioq_slot =3D 0; } - rreq->buffer_tail_slot =3D 0; } + rreq->buffer_tail_slot =3D 0; + return tail; +} + +/* + * Append a folio to the rolling queue. + */ +int netfs_buffer_append_folio(struct netfs_io_request *rreq, struct folio= *folio, + bool needs_put) +{ + struct folio_queue *tail; + unsigned int slot, order =3D folio_order(folio); + + tail =3D netfs_buffer_make_space(rreq); + if (IS_ERR(tail)) + return PTR_ERR(tail); = rreq->io_iter.count +=3D PAGE_SIZE << order; = diff --git a/fs/netfs/objects.c b/fs/netfs/objects.c index d32964e8ca5d..dd8241bc996b 100644 --- a/fs/netfs/objects.c +++ b/fs/netfs/objects.c @@ -250,3 +250,15 @@ void netfs_put_subrequest(struct netfs_io_subrequest = *subreq, bool was_async, if (dead) netfs_free_subrequest(subreq, was_async); } + +struct folio_queue *netfs_folioq_alloc(struct netfs_io_request *rreq, gfp= _t gfp) +{ + struct folio_queue *fq; + + fq =3D kmalloc(sizeof(*fq), gfp); + if (fq) { + netfs_stat(&netfs_n_folioq); + folioq_init(fq); + } + return fq; +} diff --git a/fs/netfs/write_issue.c b/fs/netfs/write_issue.c index 04e66d587f77..0929d9fd4ce7 100644 --- a/fs/netfs/write_issue.c +++ b/fs/netfs/write_issue.c @@ -153,12 +153,22 @@ static void netfs_prepare_write(struct netfs_io_requ= est *wreq, loff_t start) { struct netfs_io_subrequest *subreq; + struct iov_iter *wreq_iter =3D &wreq->io_iter; + + /* Make sure we don't point the iterator at a used-up folio_queue + * struct being used as a placeholder to prevent the queue from + * collapsing. In such a case, extend the queue. + */ + if (iov_iter_is_folioq(wreq_iter) && + wreq_iter->folioq_slot >=3D folioq_nr_slots(wreq_iter->folioq)) { + netfs_buffer_make_space(wreq); + } = subreq =3D netfs_alloc_subrequest(wreq); subreq->source =3D stream->source; subreq->start =3D start; subreq->stream_nr =3D stream->stream_nr; - subreq->io_iter =3D wreq->io_iter; + subreq->io_iter =3D *wreq_iter; = _enter("R=3D%x[%x]", wreq->debug_id, subreq->debug_index); =