linux-kernel - Re: [PATCH v2] mm: khugepaged: fix memory leak in collapse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7a31f01ac0d63788e5fbac15192c35229e1f980a.camel@mpiricsoftware.com>
Date: Mon, 24 Nov 2025 23:07:46 +0530
From: Shardul Bankar <shardul.b@...ricsoftware.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-mm@...ck.org, dev.jain@....com, david@...nel.org, 
	linux-kernel@...r.kernel.org, 
	syzbot+a785d07959bc94837d51@...kaller.appspotmail.com, 
	akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, ziy@...dia.com, 
	baolin.wang@...ux.alibaba.com, Liam.Howlett@...cle.com, npache@...hat.com, 
	ryan.roberts@....com, baohua@...nel.org, lance.yang@...ux.dev, 
	janak@...ricsoftware.com, shardulsb08@...il.com
Subject: Re: [PATCH v2] mm: khugepaged: fix memory leak in collapse_file xas
 retry loop

On Mon, 2025-11-24 at 16:21 +0000, Matthew Wilcox wrote:
> 
> Then wouldn't freeing the excess node in xas_create_range() be the
> correct fix, instead of requiring the caller to think about this?
> 
> 
Hi Matthew,

Thanks for the feedback. Agreed, this is better fixed inside xarray
instead of in collapse_file(), so callers don’t need to think about
xas_destroy() at all.

Looking at the internals, xas_nomem() only allocates a spare node into
xas->xa_alloc and xas_alloc() consumes it only if it is required. The
only point where we know that the retry loop is truly finished is after
xas_create_range() (or xas_create()) succeeds — at that point, any
remaining xa_alloc must be unused.

So to align API expectations, I’m trying to understand where you would
prefer to enforce the invariant:

  - In xas_create_range() after success, ensuring no spare remains?
  - Or in xas_create(), so that non-range callers benefit as well?

Once that API boundary is clear, I can prepare a v3 that moves the fix
into lib/xarray.c.

Thanks,
Shardul