From: Matthew Wilcox <willy@infradead.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Peter Xu <peterx@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Song Liu <songliubraving@fb.com>, Rik van Riel <riel@surriel.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Hugh Dickins <hughd@google.com>, Will Deacon <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Nick Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>, Jason Gunthorpe <jgg@ziepe.ca>,
Kevin Tian <kevin.tian@intel.com>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Steve Sistare <steven.sistare@oracle.com>,
John Hubbard <jhubbard@nvidia.com>,
"Jose A. Perez de Azpillaga" <azpijr@gmail.com>,
Josef Bacik <josef@toxicpanda.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, fuse-devel@lists.linux.dev,
linux-arch@vger.kernel.org, iommu@lists.linux.dev,
netdev@vger.kernel.org, Chris Mason <mason@kernel.org>,
stable@vger.kernel.org, Pedro Falcato <pfalcato@suse.de>
Subject: Re: [PATCH v4 1/9] mm: limit pagecache folio refcount when mapping pages
Date: Fri, 13 Nov 2026 19:45:01 +0000 [thread overview]
Message-ID: <avdovRTVITLwuit_@casper.infradead.org> (raw)
In-Reply-To: <20261112-refcount_overflow_stable-v4-1-ad3deef0bd23@kernel.org>
On Thu, Nov 12, 2026 at 11:53:20PM +0100, David Hildenbrand (Arm) wrote:
> Being able to overflow the refcount is not really big news, but it's about
> time that we do something about it because some modern technology might
> find ways to abuse it :)
Yes. My primary worry is actually it finding a path where we forget to
put the refcount on a folio and that gets exploited into a UAF. I'm not
sure the "reserve for root" aspect really helps recover from that, but
I'm not too opposed to it.
> As a short-term solution, let's introduce two folio refcount limits:
> one for ordinary consumers and one for admins. Leave some headroom
> before the refcount goes negative, which we really don't want (having
> the mapcount go negative is also not expected).
I don't think a negative refcount or mapcount is really a problem. What
matters is that we don't get to zero from below (for the refcount)
or that we don't get to 0xf000'0000 (for mapcount).
> +/* Leave separate reserves for administrators and concurrent reference gains. */
> +#define FOLIO_REF_COUNT_LIMIT (INT_MAX - (1U << 26))
> +#define FOLIO_REF_COUNT_ADMIN_LIMIT (INT_MAX - (1U << 25))
I think these specific values will generate bad code.
> +static inline bool folio_ref_count_over_limit(const struct folio *folio)
> +{
> + const unsigned int ref_count = folio_ref_count(folio);
> +
> + if (likely(ref_count < FOLIO_REF_COUNT_LIMIT))
> + return false;
I would replace this with a simple signed comparison against 0.
> static inline void folio_get(struct folio *folio)
> {
> - VM_BUG_ON_FOLIO(folio_ref_zero_or_close_to_overflow(folio), folio);
> + VM_WARN_ON_FOLIO(folio_ref_count(folio) <= 0, folio);
> folio_ref_inc(folio);
> }
And I would drop this hunk.
> diff --git a/mm/util.c b/mm/util.c
> index 80f6c714844f2..c9c3dc4b490fa 100644
> --- a/mm/util.c
> +++ b/mm/util.c
Now we have mm/folio.c, I think it should live in there.
> @@ -791,6 +791,32 @@ int folio_mc_copy(struct folio *dst, struct folio *src)
> }
> EXPORT_SYMBOL(folio_mc_copy);
>
> +bool folio_ref_count_over_limit_slowpath(const struct folio *folio,
> + unsigned int ref_count)
> +{
> + if (ref_count >= FOLIO_REF_COUNT_ADMIN_LIMIT)
> + goto over_limit;
Maybe let this go up to 0x8100'0000?
> + /* Background threads must not consume admin reserves. */
> + if (current->flags & PF_KTHREAD)
> + goto over_limit;
> + /* Neither must interrupt contexts on behalf of the interrupted task. */
> + if (!in_task())
> + goto over_limit;
> + /* Capability checks are not safe with IRQs disabled. */
> + if (irqs_disabled())
> + goto over_limit;
> + /* Use the task's credentials, which filesystem overrides cannot change. */
> + if (has_capability_noaudit(current, CAP_SYS_RESOURCE))
> + return false;
> +
> +over_limit:
> + pr_warn_ratelimited("folio:%p refcount:%d mapcount:%d mapping:%p reached refcount limit\n",
> + folio, (int)ref_count, folio_mapcount(folio),
> + folio_mapping(folio));
If it's worth doing folio->mapping, maybe also print folio->index?
In fact,
pr_warn("page: refcount:%d mapcount:%d mapping:%p index:%#lx pfn:%#lx\n",
folio_ref_count(folio), mapcount, mapping,
folio->index + idx, pfn);
might be worth pulling out into a mini helper from __dump_folio()?
next prev parent reply other threads:[~2026-11-13 19:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 22:53 [PATCH v4 0/9] mm: limit pagecache folio refcount David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 1/9] mm: limit pagecache folio refcount when mapping pages David Hildenbrand (Arm)
2026-11-13 19:45 ` Matthew Wilcox [this message]
2026-11-13 20:00 ` David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 2/9] mm: limit pagecache folio refcount when splicing into pipes David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 3/9] mm/mmu_gather: flush pending references early before the folio limit David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 4/9] iommufd: fix cleanup when adding memfd folio pins fails David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 5/9] mm/gup: limit pagecache folio refcount when grabbing references David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 6/9] net: limit folio refcount when copying skb frag references David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 7/9] net: limit folio refcount when rearranging skb frags David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 8/9] net: limit folio refcount when splicing pages into skbs David Hildenbrand (Arm)
2026-11-12 22:53 ` [PATCH v4 9/9] net: limit folio refcount when splicing from sockets David Hildenbrand (Arm)
2026-11-13 10:52 ` (subset) [PATCH v4 0/9] mm: limit pagecache folio refcount David Hildenbrand (Arm)
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=avdovRTVITLwuit_@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=azpijr@gmail.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=edumazet@kernel.org \
--cc=fuse-devel@lists.linux.dev \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=horms@kernel.org \
--cc=hughd@google.com \
--cc=iommu@lists.linux.dev \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joro@8bytes.org \
--cc=josef@toxicpanda.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kevin.tian@intel.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mason@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=miklos@szeredi.hu \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=nico.pache@linux.dev \
--cc=npiggin@gmail.com \
--cc=pabeni@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=riel@surriel.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=songliubraving@fb.com \
--cc=stable@vger.kernel.org \
--cc=steven.sistare@oracle.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox