On Tue, Nov 29, 2022 at 03:34:00PM -0500, Waiman Long wrote:
> Commit 59b57717fff8 ("blkcg: delay blkg destruction until after
> writeback has finished") delayed call to blkcg_destroy_blkgs() to
> cgwb_release_workfn(). However, it is done after a css_put() of blkcg
> which may be the final put that causes the blkcg to be freed as RCU
> read lock isn't held.
>
> By adding a css_tryget() into blkcg_destroy_blkgs() and warning its
> failure, the following stack trace was produced in a test system on
> bootup.
>
> [ 34.254240] RIP: 0010:blkcg_destroy_blkgs+0x16a/0x1a0
> :
> [ 34.339943] Call Trace:
> [ 34.342395] <TASK>
> [ 34.344510] blkcg_unpin_online+0x38/0x60
> [ 34.348523] cgwb_release_workfn+0x6a/0x200
> [ 34.352708] process_one_work+0x1e5/0x3b0
> [ 34.356742] ? rescuer_thread+0x390/0x390
> [ 34.360758] worker_thread+0x50/0x3a0
> [ 34.364425] ? rescuer_thread+0x390/0x390
> [ 34.368447] kthread+0xd9/0x100
> [ 34.371592] ? kthread_complete_and_exit+0x20/0x20
> [ 34.376386] ret_from_fork+0x22/0x30
> [ 34.379982] </TASK>
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-messages
> This confirms that a potential UAF situation can happen.
>
> Fix that by delaying the css_put() until after the blkcg_unpin_online()
> call. Also use css_tryget() in blkcg_destroy_blkgs() and issue a warning
> if css_tryget() fails with no RCU read lock held.
>
> The reproducing system can no longer produce a warning with this patch.
> All the runnable block/0* tests including block/027 were run successfully
> without failure.
--
With Best Regards,
Andy Shevchenko
