All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Guo Xuenan <guoxuenan@huawei.com>
Cc: djwong@kernel.org, dchinner@redhat.com,
	linux-xfs@vger.kernel.org, houtao1@huawei.com,
	jack.qiu@huawei.com, fangwei1@huawei.com, yi.zhang@huawei.com,
	zhengbin13@huawei.com, leo.lilong@huawei.com,
	zengheng4@huawei.com
Subject: Re: [PATCH 2/2] xfs: fix super block buf log item UAF during force shutdown
Date: Fri, 4 Nov 2022 08:44:08 +1100	[thread overview]
Message-ID: <20221103214408.GI3600936@dread.disaster.area> (raw)
In-Reply-To: <20221103083632.150458-3-guoxuenan@huawei.com>

On Thu, Nov 03, 2022 at 04:36:32PM +0800, Guo Xuenan wrote:
> xfs log io error will trigger xlog shut down, and end_io worker call
> shutdown_callbacks to unpin and release the buf log item. The race
> condition is that when there are some thread doing transaction commit
> and happened not to be intercepted by xlog_is_shutdown, then, these
> log item will be insert into CIL, when unpin and release these buf log
> item, UAF will occur. BTW, add delay before `xlog_cil_commit` while xlog
> shutdown status can increase recurrence probability.
> 
> The following call graph actually encountered this bad situation.
> fsstress                    io end worker kworker/0:1H-216
> 		             xlog_ioend_work
> 		               ->xlog_force_shutdown
> 		                 ->xlog_state_shutdown_callbacks
> 		             	 ->xlog_cil_process_committed
> 		             	   ->xlog_cil_committed
> 		             	     ->xfs_trans_committed_bulk
> ->xfs_trans_apply_sb_deltas               ->li_ops->iop_unpin(lip, 1);
>   ->xfs_trans_getsb
>     ->_xfs_trans_bjoin
>       ->xfs_buf_item_init
>         ->if (bip) { return 0;} //relog

_xfs_trans_bjoin() takes a reference to the bli.

> ->xlog_cil_commit
>   ->xlog_cil_insert_items //insert into CIL
>                                             ->xfs_buf_ioend_fail(bp);
>                                               ->xfs_buf_ioend
>                                                 ->xfs_buf_item_done
>                                                   ->xfs_buf_item_relse
>                                                     ->xfs_buf_item_free

So how is the bli getting freed here if the fstress task has just
taken an extra reference and inserted it into the CIL?

Ah, the problem is that xfs_buf_item_relse() isn't checking the
reference count before it frees the BLI. That is,
xfs_buf_item_relse() assumes that it is only called at the end of
the BLI life cycle and so doesn't check the reference count, when in
fact it clearly isn't.

Also, should we be inserting new items into the CIL if the log is
already marked as shut down?

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-11-03 21:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03  8:36 [PATCH 0/2] xfs: shutdown UAF fixes Guo Xuenan
2022-11-03  8:36 ` [PATCH 1/2] xfs: wait xlog ioend workqueue drained before tearing down AIL Guo Xuenan
2022-11-03 21:16   ` Dave Chinner
2022-11-04  7:50     ` Guo Xuenan
2022-11-04 15:46       ` Darrick J. Wong
2022-11-05  3:32         ` Guo Xuenan
2022-11-03  8:36 ` [PATCH 2/2] xfs: fix super block buf log item UAF during force shutdown Guo Xuenan
2022-11-03 21:44   ` Dave Chinner [this message]
2022-11-07 14:27 ` [PATCH v2 1/2] xfs: wait xlog ioend workqueue drained before tearing down AIL Guo Xuenan
2022-11-07 14:27   ` [PATCH v2 2/2] xfs: fix super block buf log item UAF during force shutdown Guo Xuenan
2022-11-08 14:06     ` [PATCH v3 1/2] xfs: wait xlog ioend workqueue drained before tearing down AIL Guo Xuenan
2022-11-15 23:23       ` Darrick J. Wong
2022-11-17  1:18         ` Guo Xuenan
2022-11-16  6:02       ` Dave Chinner
2022-11-17  2:12         ` Guo Xuenan
2022-11-07 17:13   ` [PATCH v2 " Darrick J. Wong
2022-11-08  2:44     ` Guo Xuenan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221103214408.GI3600936@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fangwei1@huawei.com \
    --cc=guoxuenan@huawei.com \
    --cc=houtao1@huawei.com \
    --cc=jack.qiu@huawei.com \
    --cc=leo.lilong@huawei.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=yi.zhang@huawei.com \
    --cc=zengheng4@huawei.com \
    --cc=zhengbin13@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.