linux-kernel - Re: [PATCH v3] kho: validate preserved memory map during population

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: <CA+CK2bC2BQBgtgudZ3-Tpc9ctJEaiFJjx9gNuysXLU1LGpf6OA@mail.gmail.com>
Date: Tue, 23 Dec 2025 08:39:50 -0500
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: akpm@...ux-foundation.org, rppt@...nel.org, graf@...zon.com, 
	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, linux-mm@...ck.org, 
	ricardo.neri-calderon@...ux.intel.com
Subject: Re: [PATCH v3] kho: validate preserved memory map during population

> > Previously, kho_populate() would succeed regardless of the memory map's
> > state, reserving the incoming scratch regions in memblock. However,
> > kho_memory_init() would later fail to deserialize the empty map. By that
> > time, the scratch regions were already registered, leading to partial
> > initialization and subsequent list corruption (double-free) during
> > kho_init().
>
> Nit: I am guessing the double-free is the scratch regions being freed
> twice? Can you please write that out explicitly?

Sure.

> > +     mem_map_phys = kho_get_mem_map_phys(fdt);
> > +     if (!mem_map_phys) {
> > +             pr_warn("setup: handover FDT (0x%llx) present but no preserved memory found\n",
> > +                     fdt_phys);
>
> Enabling KHO but not using it is a perfectly normal use case. This
> should not be a warning. I don't think we should print anything here
> TBH.

That is fair, I considered pr_info(), but I think you are right, lets
just remove print.

>
> > +             err = -ENOENT;
> > +             goto out;
> > +     }
> > +
> >       scratch = early_memremap(scratch_phys, scratch_len);
> >       if (!scratch) {
> >               pr_warn("setup: failed to memremap scratch (phys=0x%llx, len=%lld)\n",
> > @@ -1515,6 +1517,7 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
> >
> >       kho_in.fdt_phys = fdt_phys;
> >       kho_in.scratch_phys = scratch_phys;
> > +     kho_in.mem_map_phys = mem_map_phys;
>
> Nit: not a fan of duplicating information. This is already contained in
> the FDT. Perhaps make kho_memory_init() also call
> kho_get_mem_map_phys()? And while at it, perhaps make it
> kho_get_mem_map() and the return type struct khoser_mem_chunk * ?

I prefer the current approach, fetch from FDT once, it is just a single address.

> No strong opinion, so fine either way, but I do think it is cleaner.

Thank you for the review.

Pasha