linux-kernel - Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2vxzikcoa4g1.fsf@kernel.org>
Date: Mon, 26 Jan 2026 14:28:30 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Alexander Graf <graf@...zon.com>,  Mike Rapoport <rppt@...nel.org>,
  Pasha Tatashin <pasha.tatashin@...een.com>,  Pratyush Yadav
 <pratyush@...nel.org>,  linux-kernel@...r.kernel.org,
  kexec@...ts.infradead.org,  linux-mm@...ck.org,  usamaarif642@...il.com,
  rmikey@...a.com,  clm@...com,  riel@...riel.com,  kernel-team@...a.com,
  SeongJae Park <sj@...nel.org>
Subject: Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain

Hi Breno,

On Mon, Jan 26 2026, Breno Leitao wrote:

> On Wed, Jan 21, 2026 at 06:50:38AM -0800, Breno Leitao wrote:
>> +static __init int kho_populate_kexec_metadata(void)
>> +{
>> +	struct kho_kexec_metadata *metadata;
>> +	int err;
>> +
>> +	metadata = kho_alloc_preserve(sizeof(*metadata));
>> +	if (IS_ERR(metadata))
>> +		return PTR_ERR(metadata);
>> +
>> +	strscpy(metadata->previous_release, init_uts_ns.name.release,
>> +		sizeof(metadata->previous_release));
>> +	/* kho_in.kexec_count is set to 0 on cold boot */
>> +	metadata->kexec_count = kho_in.kexec_count + 1;
>> +
>> +	err = kho_add_subtree(KHO_METADATA_NODE_NAME, metadata);
>
> There is a hidden bug in here when CONFIG_KEXEC_HANDOVER_DEBUGFS is set.

Good catch!

>
> kho_add_subtree() expects a fdt as the second argument, and we are
> passing a pure C struct. That works fine, except for debugfs, which
> does:
>
>  1. kho_add_subtree() calls kho_debugfs_fdt_add()
>  2. kho_debugfs_fdt_add() calls __kho_debugfs_fdt_add()
>  3. __kho_debugfs_fdt_add() executes fdt_totalsize(fdt)
>
> The fdt_totalsize() macro reads bytes 4-7 of the input as a big-endian u32, and
> this will hit struct kho_kexec_metadata, given I am passing a C struct instead
> of a FDT.
>
>   struct kho_kexec_metadata {
>       char previous_release[__NEW_UTS_LEN + 1];  // 65 bytes
>       u32 kexec_count;
>   } __packed;
>
> Bytes 4-7 would be characters from previous_release (e.g., "0-rc" from
> "6.19.0-rc4..."). Interpreted as big-endian u32, this gives a garbage size
> value.
>
> The alternatives I see here are:
>
>  1) Come back to FDT instead of plain C struct, similarly to the previous
>     version [1]
>  2) Created some helpers to treat C struct fields specially just for this
>     feature, and we can do it later if we have more users.
>  3) Move this kexec_metadata to work on top of LUO (similarly to memfd), but
>     that would be an unnecessary dependency just to have this kexec_metadata.
>
> That said, for the next version, I am coming back to to FDT.

Please, no. Don't go back to it just for the sake of this bug.

I think KHO's assumption that the subtree will always point to an FDT is
broken, and we should fix that. I think KHO should expose the blob of
serialized data and let userspace figure out what the format is and how
to decode it.

To do that, we would need to update kho_add_subtree() to take a size
parameter from callers, and pass that down to debugfs code. I count 3
callers of kho_add_subtree() - memblock, LUO, and test_kho. I think all
3 should be fairly easy to update, but I am happy to help out if you
need.

>
> Link: https://lore.kernel.org/all/20260108-kho-v3-0-b1d6b7a89342@debian.org/ [1]
>
> --breno

-- 
Regards,
Pratyush Yadav