linux-kernel - Re: [PATCH v8 14/18] mm: memfd

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: <20260113140927.1074142-1-clm@meta.com>
Date: Tue, 13 Jan 2026 06:09:23 -0800
From: Chris Mason <clm@...a.com>
To: Pasha Tatashin <pasha.tatashin@...een.com>
CC: Chris Mason <clm@...a.com>, <jasonmiu@...gle.com>, <graf@...zon.com>,
        <rppt@...nel.org>, <dmatlack@...gle.com>, <rientjes@...gle.com>,
        <corbet@....net>, <rdunlap@...radead.org>,
        <ilpo.jarvinen@...ux.intel.com>, <kanie@...ux.alibaba.com>,
        <ojeda@...nel.org>, <aliceryhl@...gle.com>, <masahiroy@...nel.org>,
        <akpm@...ux-foundation.org>, <tj@...nel.org>, <yoann.congal@...le.fr>,
        <mmaurer@...gle.com>, <roman.gushchin@...ux.dev>,
        <chenridong@...wei.com>, <axboe@...nel.dk>, <mark.rutland@....com>,
        <jannh@...gle.com>, <vincent.guittot@...aro.org>, <hannes@...xchg.org>,
        <dan.j.williams@...el.com>, <david@...hat.com>,
        <joel.granados@...nel.org>, <rostedt@...dmis.org>,
        <anna.schumaker@...cle.com>, <song@...nel.org>, <linux@...ssschuh.net>,
        <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-mm@...ck.org>, <gregkh@...uxfoundation.org>,
        <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
        <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <rafael@...nel.org>, <dakr@...nel.org>,
        <bartosz.golaszewski@...aro.org>, <cw00.choi@...sung.com>,
        <myungjoo.ham@...sung.com>, <yesanishhere@...il.com>,
        <Jonathan.Cameron@...wei.com>, <quic_zijuhu@...cinc.com>,
        <aleksander.lobakin@...el.com>, <ira.weiny@...el.com>,
        <andriy.shevchenko@...ux.intel.com>, <leon@...nel.org>,
        <lukas@...ner.de>, <bhelgaas@...gle.com>, <wagi@...nel.org>,
        <djeffery@...hat.com>, <stuart.w.hayes@...il.com>, <ptyadav@...zon.de>,
        <lennart@...ttering.net>, <brauner@...nel.org>,
        <linux-api@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
        <saeedm@...dia.com>, <ajayachandra@...dia.com>, <jgg@...dia.com>,
        <parav@...dia.com>, <leonro@...dia.com>, <witu@...dia.com>,
        <hughd@...gle.com>, <skhawaja@...gle.com>, <chrisl@...nel.org>
Subject: Re: [PATCH v8 14/18] mm: memfd_luo: allow preserving memfd

On Tue, 25 Nov 2025 11:58:44 -0500 Pasha Tatashin <pasha.tatashin@...een.com> wrote:

Hi everyone,

I'm running the v6.19 mm commits through patch review automation, and this
commit was flagged.  I don't know this code well, but it looks like it
might be a real bug.

[AI review output below]

> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> new file mode 100644
> index 0000000000000..4f6ba63b43105
> --- /dev/null
> +++ b/mm/memfd_luo.c

[ ... ]

> +static int memfd_luo_retrieve_folios(struct file *file,
> +				     struct memfd_luo_folio_ser *folios_ser,
> +				     u64 nr_folios)
> +{
> +	struct inode *inode = file_inode(file);
> +	struct address_space *mapping = inode->i_mapping;
> +	struct folio *folio;
> +	int err = -EIO;
> +	long i;
> +
> +	for (i = 0; i < nr_folios; i++) {

[ ... ]

> +		err = shmem_add_to_page_cache(folio, mapping, index, NULL,
> +					      mapping_gfp_mask(mapping));
> +		if (err) {
> +			pr_err("shmem: failed to add to page cache folio index %ld: %d\n",
> +			       i, err);
> +			goto unlock_folio;
> +		}
> +
> +		if (flags & MEMFD_LUO_FOLIO_UPTODATE)
> +			folio_mark_uptodate(folio);
> +		if (flags & MEMFD_LUO_FOLIO_DIRTY)
> +			folio_mark_dirty(folio);
> +
> +		err = shmem_inode_acct_blocks(inode, 1);
> +		if (err) {
> +			pr_err("shmem: failed to account folio index %ld: %d\n",
> +			       i, err);
> +			goto unlock_folio;
> +		}

When shmem_inode_acct_blocks() fails here, the folio has already been
added to the page cache by shmem_add_to_page_cache(). Should the folio be
removed from the page cache before going to unlock_folio?

Looking at shmem_alloc_and_add_folio() in mm/shmem.c, when
shmem_inode_acct_blocks() fails after the folio has been added, it calls
filemap_remove_folio() to remove it:

    error = shmem_inode_acct_blocks(inode, pages);
    if (error) {
        ...
        if (error) {
            filemap_remove_folio(folio);
            goto unlock;
        }
    }

Without this, the folio remains in the page cache (counted in
mapping->nrpages) but info->alloced is not incremented (since
shmem_recalc_inode is not called). This could cause shmem accounting
inconsistency.