linux-kernel - Re: [PATCH 2/2] 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: <2vxzikc4so0g.fsf@kernel.org>
Date: Tue, 10 Feb 2026 14:53:51 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Mike Rapoport <rppt@...nel.org>,
  Alexander Graf <graf@...zon.com>,  Pasha Tatashin
 <pasha.tatashin@...een.com>,  Hugh Dickins <hughd@...gle.com>,  Baolin
 Wang <baolin.wang@...ux.alibaba.com>,  Andrew Morton
 <akpm@...ux-foundation.org>,  Samiullah Khawaja <skhawaja@...gle.com>,
  kexec@...ts.infradead.org,  linux-mm@...ck.org,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] mm: memfd_luo: preserve file seals

On Tue, Feb 10 2026, Jason Gunthorpe wrote:

> On Tue, Feb 10, 2026 at 02:10:45PM +0100, Pratyush Yadav wrote:
>> Hi Jason,
>> 
>> On Mon, Jan 26 2026, Jason Gunthorpe wrote:
>> 
>> > On Sun, Jan 25, 2026 at 02:03:29PM +0200, Mike Rapoport wrote:
>> >> > @@ -67,11 +72,13 @@ struct memfd_luo_folio_ser {
>> >> >  struct memfd_luo_ser {
>> >> >  	u64 pos;
>> >> >  	u64 size;
>> >> > +	u64 seals:8;
>> >> 
>> >> Kernel uABI defines seals as unsigned int, I think we can spare u32 for
>> >> them and reserve a u32 flags for other memfd flags (MFD_CLOEXEC,
>> >> MFD_HUGETLB etc).
>> >
>> > It is a bit worse than that, the "v2" version is only going to support
>> > some set of seals (probably the set defined in v6.19) and if there are
>> > new seals down the road then this needs a version bump.
>> 
>> If we are running say kernel X, then X + 1 will always support a
>> superset of the seals, since the seals are UAPI. So it should be able to
>> handle all the seals that are given to it by X. This only becomes a
>> problem on rollbacks. Is this what you are worried about or am I missing
>> something?
>
> I think you need a check at some point only permitting seals that are
> defined right now.
>
> Eg some future v7.19 kernel has MEMFD_SEAL_XX it should not be allowed
> through luo until the API is bumped to v3

Makes sense. Will add.

-- 
Regards,
Pratyush Yadav