From: Andrew Morton <akpm@linux-foundation.org>
To: Daehyeon Ko <4ncienth@gmail.com>
Cc: muchun.song@linux.dev, osalvador@suse.de, david@kernel.org,
tj@kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb_cgroup: prevent use-after-free during cgroup offlining
Date: Tue, 20 Oct 2026 10:30:57 -0700 [thread overview]
Message-ID: <20261020103057.8066217f6f6fc5b3ed84c90b@linux-foundation.org> (raw)
In-Reply-To: <20261020100345.1677643-1-4ncienth@gmail.com>
On Tue, 20 Oct 2026 19:03:45 +0900 Daehyeon Ko <4ncienth@gmail.com> wrote:
> A normal hugetlb charge obtains the current task's hugetlb cgroup with
> css_tryget(), charges its page counter, and drops the CSS reference before
> the folio is committed under hugetlb_lock.
>
> The task can be migrated while the allocation is in progress. If the old
> CSS is then offlined, its final active-folio scan can finish before the
> charge becomes visible. The allocation can subsequently charge that dying
> CSS and commit its pointer to the folio. Once the CSS is freed, uncharging
> the folio accesses the freed hugetlb_cgroup, including its page counter and
> per-node usage.
>
> Keep the reference acquired by the charge until commit or cancellation. At
> commit time, while holding hugetlb_lock, move an uncommitted charge out of
> each dying CSS to the first live ancestor. The hierarchical charge already
> includes every ancestor, so moving it only requires canceling each dying
> CSS's local count.
>
> This orders commit against the offline active-folio scan: either the scan
> runs after commit and reparents the folio, or commit observes the dying CSS
> after the scan and selects a live ancestor. The retained reference also
> keeps the originally selected hugetlb_cgroup alive through this decision.
> Reservation charges retain their existing CSS lifetime and are not
> reparented.
>
> On an unmodified v7.3 kernel with a 128-page 2 MiB pool, a
> capability-free uid 1000 allocator racing administrator rmdir reproduced
> KASAN writes to a freed hugetlb_cgroup in three of three boots. Controller
> disable reproduced the same fault. With this change, 5,000 rmdir rounds
> with 1,075,055 successful faults and 2,000 controller-disable rounds with
> 1,707,348 successful faults completed without KASAN, LOCKDEP, page-counter,
> or refcount reports.
>
> AI-assisted source review was used to identify the race and to help draft
> the reproducer and fix. The interleaving and the resulting allocation,
> free, and use-after-free stacks were verified with tracefs and KASAN.
Thanks. I ran this through my evolving reviewbot. It liked the change
and agreed with it.
One claim:
>
> ...
>
> @@ -419,15 +438,17 @@ static void __hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
> struct hugetlb_cgroup *h_cg,
> bool rsvd)
> {
> - if (hugetlb_cgroup_disabled() || !h_cg)
> + if (!h_cg)
> return;
>
> - page_counter_uncharge(__hugetlb_cgroup_counter_from_cgroup(h_cg, idx,
> - rsvd),
> - nr_pages);
> + if (!hugetlb_cgroup_disabled()) {
This test is unnecessary. Once h_cg is non-NULL, a successful charge
necessarily came from an enabled controller, and cgroup_disable= is a
boot-time static-key setting. Please just unconditionally call
page_counter_uncharge() after the existing !h_cg check, followed by
css_put().
> + struct page_counter *counter;
>
> - if (rsvd)
> - css_put(&h_cg->css);
> + counter = __hugetlb_cgroup_counter_from_cgroup(h_cg, idx, rsvd);
> + page_counter_uncharge(counter, nr_pages);
> + }
> +
> + css_put(&h_cg->css);
> }
>
> void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
prev parent reply other threads:[~2026-10-20 17:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 10:03 Daehyeon Ko
2026-10-20 17:30 ` Andrew Morton [this message]
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=20261020103057.8066217f6f6fc5b3ed84c90b@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=4ncienth@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®