bootconfig: Fix maximum-depth key export

I found that bootconfig accepts a key with the supported maximum of 16
components but fails to reconstruct its full name. This stops the tool's
list output and prevents the kernel from creating /proc/bootconfig.

Patch 1 moves the capacity check before collecting the next component.
Patch 2 adds a full-output comparison to the existing bootconfig suite,
including a check that 17-component keys are still rejected.

Validation on mainline 05441d697f7f:
- GCC 14.2 and Clang 19.1, -Wall -Werror: 82 tool checks pass each.
- The added test fails before the fix and passes after it. The independent
  nine-case boundary/round-trip matrix changes from 5 pass/4 fail to 9 pass.
- GCC ASan/UBSan: the reproducer and all nine matrix cases pass.
- Real arm64 kernels under QEMU TCG: depth 15 passes before and after;
  depth 16 loses /proc/bootconfig before, and exports the exact key/value
  after. Both kernels use identical configurations and initramfs inputs.
- A full baseline W=1 build succeeds with existing warnings in arm64
  sys.c/traps.c and sched/rt.c; bootconfig has none. The fixed incremental
  kernel build recompiles lib/bootconfig.o and relinks without warnings.

This is a long-standing functional bug, present in the feature's original
commit. Mainline, linux-next and the bootconfig for-next tree retain it;
no matching posted fix was found in the checked public patch records.

I used OpenAI Codex to verify the issue and develop the fix. I reviewed
the changes and wrote and ran the regression tests. Codex also helped
with additional checks of the boundary cases.

Testing is limited to little-endian arm64 with external initramfs
bootconfig; other architectures, embedded/forced bootconfig, allmodconfig
and fault injection have not been verified.

Zhiqi Zhang (2):
  bootconfig: Allow keys with the maximum supported depth
  tools/bootconfig: Test listing keys at the maximum depth

 lib/bootconfig.c                    |  2 +-
 tools/bootconfig/test-bootconfig.sh | 10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

5 more lines

xbc_verify_tree() accepts keys with XBC_DEPTH_MAX (16) components,
but xbc_node_compose_key_after() returns -ERANGE immediately after
storing the sixteenth component. It rejects the key before discovering
that there are no more ancestors to collect.

For example, a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p = value can be attached
to an initrd successfully. However, bootconfig -l stops listing and
prints "Failed to compose key -34". In the kernel, the same error
propagates through copy_xbc_key_value_list() during its length probe,
so proc_boot_config_init() returns before creating /proc/bootconfig.

Check the array capacity before storing the next component. This lets
exactly XBC_DEPTH_MAX components be composed while retaining the check
before any out-of-bounds store.

I found this issue while reviewing bootconfig's depth handling and used
OpenAI Codex to verify the failure and develop the fix. I reviewed the
change and wrote and ran the regression tests.

Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support")
Cc: <redacted>
Signed-off-by: Zhiqi Zhang <redacted>
---
 lib/bootconfig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index 819685d6c68d..a4aae9a9abca 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c

@@ -428,9 +428,9 @@ int __init xbc_node_compose_key_after(struct xbc_node *root,
 		node = xbc_node_get_parent(node);
 
 	while (node && node != root) {
-		keys[depth++] = xbc_node_index(node);
 		if (depth == XBC_DEPTH_MAX)
 			return -ERANGE;
+		keys[depth++] = xbc_node_index(node);
 		node = xbc_node_get_parent(node);
 	}
 	if (!node && root)

-- 
2.54.0 (Apple Git-157)

Check that a key with 16 components can be attached to an initrd and
listed in full, and that a key with 17 components is still rejected.
Compare the complete list output instead of relying on the tool's
exit status: a failed key composition currently stops listing without
changing that status.

The existing good sample checks exercise the compact tree renderer,
which does not use xbc_node_compose_key_after() and therefore misses
its depth boundary error.

I wrote and ran these regression tests after reviewing the fix.

Signed-off-by: Zhiqi Zhang <redacted>
---
 tools/bootconfig/test-bootconfig.sh | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/bootconfig/test-bootconfig.sh b/tools/bootconfig/test-bootconfig.sh
index 530ce7e28d63..d19747e47890 100755
--- a/tools/bootconfig/test-bootconfig.sh
+++ b/tools/bootconfig/test-bootconfig.sh

@@ -100,6 +100,16 @@ xpass $BOOTCONF -a $TEMPCONF $INITRD
 printf "badnode\n" >> $TEMPCONF
 xfail $BOOTCONF -a $TEMPCONF $INITRD
 
+echo "Max key depth check"
+
+printf 'a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p = "value"\n' > $TEMPCONF
+xpass $BOOTCONF -a $TEMPCONF $INITRD
+$BOOTCONF -l $INITRD > $OUTFILE
+xpass cmp $TEMPCONF $OUTFILE
+
+printf 'a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q = "value"\n' > $TEMPCONF
+xfail $BOOTCONF -a $TEMPCONF $INITRD
+
 echo "Max filesize check"
 
 # Max size is 32767 (including terminal byte)

-- 
2.54.0 (Apple Git-157)

On Wed,  4 Nov 2026 15:37:41 +0800, Zhiqi Zhang [off-list ref] wrote:

xbc_verify_tree() accepts keys with XBC_DEPTH_MAX (16) components,
but xbc_node_compose_key_after() returns -ERANGE immediately after
storing the sixteenth component. It rejects the key before discovering
that there are no more ancestors to collect.

For example, a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p = value can be attached
to an initrd successfully. However, bootconfig -l stops listing and
prints "Failed to compose key -34". In the kernel, the same error
propagates through copy_xbc_key_value_list() during its length probe,
so proc_boot_config_init() returns before creating /proc/bootconfig.

Check the array capacity before storing the next component. This lets
exactly XBC_DEPTH_MAX components be composed while retaining the check
before any out-of-bounds store.

Ah, good catch! Let me pick it.

Thank you!

-- 
Masami Hiramatsu (Google) [off-list ref]

On Wed,  4 Nov 2026 15:37:42 +0800, Zhiqi Zhang [off-list ref] wrote:

Check that a key with 16 components can be attached to an initrd and
listed in full, and that a key with 17 components is still rejected.
Compare the complete list output instead of relying on the tool's
exit status: a failed key composition currently stops listing without
changing that status.

The existing good sample checks exercise the compact tree renderer,
which does not use xbc_node_compose_key_after() and therefore misses
its depth boundary error.

I wrote and ran these regression tests after reviewing the fix.

Signed-off-by: Zhiqi Zhang <redacted>

Thanks, this also looks good to me.

-- 
Masami Hiramatsu (Google) [off-list ref]