Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2676622imj; Mon, 11 Feb 2019 06:53:35 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia5owkBDLCwXlYmQ0B4yQ75doImQ70INihvLcfysTWDmgT6TmWP3/zYf09gYNkexD6nMz0i X-Received: by 2002:a62:6b8a:: with SMTP id g132mr37230490pfc.201.1549896815184; Mon, 11 Feb 2019 06:53:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549896815; cv=none; d=google.com; s=arc-20160816; b=WFUex9UnbPrJ+11839e4vHPlc4/3P7oCGtDT7/pI9yn6R35203dVTDgi/VSzfmGXUw nVG5HeDNnf6KiMCZTT6ZT/1B3AbIHY/PTv36VOdv0T2Z/n1xg6kjn8Kz/i7KVX2F+A07 YnUta1IWPhTaGC7AefGnnUQ1fUU30p1w2lCvLhpBbcSsu2vbhpv+/2ecdr6ardNOzB0Z kgLphhpPLa/nGGtVuoxE3Pe0Izi2PL8cZ9dt0d0sqdsK9AEtwd6nN/IcmfbnCLOUlYye HwXAwLTogAR4DIf4OALxUP0qkVY7qwrunTdp9Elss4QO6h9AU9ckmdENgMSdDDwiohxp VAdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=S9rR/uonMhXKwAnTtEA8uZcqiKELPDtSMdjDZkCE6Rc=; b=UWR9BTYhOD3HMDDIfjCuMfuWJe/4WXdQUFc0871ch8ABKg4om3V7+udVDcgmn8ehHP P2quWe0SAF1LFcheVV3IOD2u1gLnRgmjzbIGQ9UR8Xpj0pZCeHAlcMmcnOxUBJPJlNEj nToLIFNC8ZCwBjUwgP0KdFc1gqQppHd2OU3PztnT9Mxu9Lj9VPVPd0WXiCX/M4gYBu11 gKeNOtc8yy3YOmdWAnwr0gK+TJtXGtx+/ttkQFv0LTwFnUChBSyrXbQy05uABIbN7e34 sI7Wo1zucBrpTW8wCVHWubzYsHKMStIQzDJfwtLy0BWLOsnfGdI2cLudN4PFe4atVS2c gRxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jl2d3kp5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f35si9381688plh.399.2019.02.11.06.53.18; Mon, 11 Feb 2019 06:53:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jl2d3kp5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388409AbfBKOwU (ORCPT + 99 others); Mon, 11 Feb 2019 09:52:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:38498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387619AbfBKOwS (ORCPT ); Mon, 11 Feb 2019 09:52:18 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A8D2D2081B; Mon, 11 Feb 2019 14:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549896737; bh=9+FFu1JwKgwJM9K971Kqa9e+BDxxVf7c9wRH60atDF0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jl2d3kp5WkhyZvET6abgjvZv2HuD3aprCLDdgXz2MaPMzAoOQVn8+xz/ifd/Do2nq pyaFMvPwbdpQkHrlzrgEFhJsJ+gqIy+buEXkBm+dNYRAmuKtNz06Jchreo90UTDbc0 uGMCwWJBcqVf32NKQ8QIWqqwxg/3Nkcg4RvorvDU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , Dave Chinner , Christoph Hellwig , "Darrick J. Wong" , Luis Chamberlain , Sasha Levin Subject: [PATCH 4.19 253/313] xfs: fix transient reference count error in xfs_buf_resubmit_failed_buffers Date: Mon, 11 Feb 2019 15:18:53 +0100 Message-Id: <20190211141910.239114958@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190211141852.749630980@linuxfoundation.org> References: <20190211141852.749630980@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ commit d43aaf1685aa471f0593685c9f54d53e3af3cf3f upstream. When retrying a failed inode or dquot buffer, xfs_buf_resubmit_failed_buffers() clears all the failed flags from the inde/dquot log items. In doing so, it also drops all the reference counts on the buffer that the failed log items hold. This means it can drop all the active references on the buffer and hence free the buffer before it queues it for write again. Putting the buffer on the delwri queue takes a reference to the buffer (so that it hangs around until it has been written and completed), but this goes bang if the buffer has already been freed. Hence we need to add the buffer to the delwri queue before we remove the failed flags from the log items attached to the buffer to ensure it always remains referenced during the resubmit process. Reported-by: Josef Bacik Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Luis Chamberlain Signed-off-by: Sasha Levin --- fs/xfs/xfs_buf_item.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index 12d8455bfbb2..010db5f8fb00 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -1233,9 +1233,23 @@ xfs_buf_iodone( } /* - * Requeue a failed buffer for writeback + * Requeue a failed buffer for writeback. * - * Return true if the buffer has been re-queued properly, false otherwise + * We clear the log item failed state here as well, but we have to be careful + * about reference counts because the only active reference counts on the buffer + * may be the failed log items. Hence if we clear the log item failed state + * before queuing the buffer for IO we can release all active references to + * the buffer and free it, leading to use after free problems in + * xfs_buf_delwri_queue. It makes no difference to the buffer or log items which + * order we process them in - the buffer is locked, and we own the buffer list + * so nothing on them is going to change while we are performing this action. + * + * Hence we can safely queue the buffer for IO before we clear the failed log + * item state, therefore always having an active reference to the buffer and + * avoiding the transient zero-reference state that leads to use-after-free. + * + * Return true if the buffer was added to the buffer list, false if it was + * already on the buffer list. */ bool xfs_buf_resubmit_failed_buffers( @@ -1243,16 +1257,16 @@ xfs_buf_resubmit_failed_buffers( struct list_head *buffer_list) { struct xfs_log_item *lip; + bool ret; + + ret = xfs_buf_delwri_queue(bp, buffer_list); /* - * Clear XFS_LI_FAILED flag from all items before resubmit - * - * XFS_LI_FAILED set/clear is protected by ail_lock, caller this + * XFS_LI_FAILED set/clear is protected by ail_lock, caller of this * function already have it acquired */ list_for_each_entry(lip, &bp->b_li_list, li_bio_list) xfs_clear_li_failed(lip); - /* Add this buffer back to the delayed write list */ - return xfs_buf_delwri_queue(bp, buffer_list); + return ret; } -- 2.19.1