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;
Date:   Wed, 30 Nov 2022 14:39:46 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Waiman Long <longman@redhat.com>
Cc:     Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
        cgroups@vger.kernel.org, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Ming Lei <ming.lei@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michal =?iso-8859-1?Q?Koutn=FD?= <mkoutny@suse.com>,
        Hillf Danton <hdanton@sina.com>,
        Chaitanya Kulkarni <chaitanyak@nvidia.com>,
        Bart Van Assche <bvanassche@acm.org>,
        Josef Bacik <josef@toxicpanda.com>,
        Yi Zhang <yi.zhang@redhat.com>
Subject: Re: [PATCH-block v2] bdi, blk-cgroup: Fix potential UAF of blkcg
Message-ID: <Y4dPEtGuQ2A3L+Ww@smile.fi.intel.com>
References: <20221129203400.1456100-1-longman@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221129203400.1456100-1-longman@redhat.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

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