Re: [PATCH v4 1/9] mm: limit pagecache folio refcount when mapping pages

[Matthew Wilcox]

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()?