kernel/git/stable/linux.git/lib/bootconfig.c, branch linux-5.15.y

bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()

2026-08-23T12:17:24+00:00

[ Upstream commit dec4d8118c179b3d12bca7e609054c6011c4f2ce ] xbc_snprint_cmdline() is meant to be called twice: first with buf=NULL, size=0 to probe the rendered length, then with a real buffer to fill it (the standard snprintf() two-pass pattern). The probe call makes the function compute "buf + size" (NULL + 0) and, on every iteration, advance "buf += ret" from that NULL base and pass the result back into snprintf(). Pointer arithmetic on a NULL pointer is undefined behavior. It is harmless in the in-kernel callers today, but the follow-up patches run this same code in the userspace tools/bootconfig parser at kernel build time, where host UBSan / FORTIFY_SOURCE abort the build. Track a running written length (size_t) instead of mutating @buf, and only form "buf + len" when @buf is non-NULL. snprintf(NULL, 0, ...) is itself well defined and returns the would-be length, so the two-pass "probe then fill" usage returns identical byte counts. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-1-24ab72139c29@debian.org/ Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c

2026-08-23T12:17:24+00:00

[ Upstream commit 5a643e4623238e14b03d75ca0d4eda0645720cee ] Move xbc_snprint_cmdline() from init/main.c to lib/bootconfig.c so the function (and its xbc_namebuf scratch buffer) becomes part of the shared parser library. tools/bootconfig already compiles lib/bootconfig.c directly, which lets a follow-up patch reuse the same renderer in the userspace tool to convert a bootconfig file into a flat cmdline string at build time. No functional change. Link: https://lore.kernel.org/all/20260508-bootconfig_using_tools-v1-1-1132219aa773@debian.org/ Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: dec4d8118c17 ("bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

lib/bootconfig: check xbc_init_node() return in override path

2026-04-18T08:33:22+00:00

[ Upstream commit bb288d7d869e86d382f35a0e26242c5ccb05ca82 ] The ':=' override path in xbc_parse_kv() calls xbc_init_node() to re-initialize an existing value node but does not check the return value. If xbc_init_node() fails (data offset out of range), parsing silently continues with stale node data. Add the missing error check to match the xbc_add_node() call path which already checks for failure. In practice, a bootconfig using ':=' to override a value near the 32KB data limit could silently retain the old value, meaning a security-relevant boot parameter override (e.g., a trace filter or debug setting) would not take effect as intended. Link: https://lore.kernel.org/all/20260318155847.78065-2-objecting@objecting.org/ Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key") Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin

lib/bootconfig: check bounds before writing in __xbc_open_brace()

2026-04-18T08:33:16+00:00

commit 560f763baa0f2c9a44da4294c06af071405ac46f upstream. The bounds check for brace_index happens after the array write. While the current call pattern prevents an actual out-of-bounds access (the previous call would have returned an error), the write-before-check pattern is fragile and would become a real out-of-bounds write if the error return were ever not propagated. Move the bounds check before the array write so the function is self-contained and safe regardless of caller behavior. Link: https://lore.kernel.org/all/20260312191143.28719-3-objecting@objecting.org/ Fixes: ead1e19ad905 ("lib/bootconfig: Fix a bug of breaking existing tree nodes") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

lib/bootconfig: fix snprintf truncation check in xbc_node_compose_key_after()

2026-04-18T08:33:16+00:00

commit 1120a36bb1e9b9e22de75ecb4ef0b998f73a97f1 upstream. snprintf() returns the number of characters that would have been written excluding the NUL terminator. Output is truncated when the return value is >= the buffer size, not just > the buffer size. When ret == size, the current code takes the non-truncated path, advancing buf by ret and reducing size to 0. This is wrong because the output was actually truncated (the last character was replaced by NUL). Fix by using >= so the truncation path is taken correctly. Link: https://lore.kernel.org/all/20260312191143.28719-4-objecting@objecting.org/ Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error

2026-04-18T08:33:16+00:00

commit 39ebc8d7f561e1b64eca87353ef9b18e2825e591 upstream. __xbc_open_brace() pushes entries with post-increment (open_brace[brace_index++]), so brace_index always points one past the last valid entry. xbc_verify_tree() reads open_brace[brace_index] to report which brace is unclosed, but this is one past the last pushed entry and contains stale/zero data, causing the error message to reference the wrong node. Use open_brace[brace_index - 1] to correctly identify the unclosed brace. brace_index is known to be > 0 here since we are inside the if (brace_index) guard. Link: https://lore.kernel.org/all/20260312191143.28719-2-objecting@objecting.org/ Fixes: ead1e19ad905 ("lib/bootconfig: Fix a bug of breaking existing tree nodes") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

memblock: introduce saner 'memblock_free_ptr()' interface

2021-09-14T20:23:22+00:00

The boot-time allocation interface for memblock is a mess, with 'memblock_alloc()' returning a virtual pointer, but then you are supposed to free it with 'memblock_free()' that takes a _physical_ address. Not only is that all kinds of strange and illogical, but it actually causes bugs, when people then use it like a normal allocation function, and it fails spectacularly on a NULL pointer: https://lore.kernel.org/all/20210912140820.GD25450@xsang-OptiPlex-9020/ or just random memory corruption if the debug checks don't catch it: https://lore.kernel.org/all/61ab2d0c-3313-aaab-514c-e15b7aa054a0@suse.cz/ I really don't want to apply patches that treat the symptoms, when the fundamental cause is this horribly confusing interface. I started out looking at just automating a sane replacement sequence, but because of this mix or virtual and physical addresses, and because people have used the "__pa()" macro that can take either a regular kernel pointer, or just the raw "unsigned long" address, it's all quite messy. So this just introduces a new saner interface for freeing a virtual address that was allocated using 'memblock_alloc()', and that was kept as a regular kernel pointer. And then it converts a couple of users that are obvious and easy to test, including the 'xbc_nodes' case in lib/bootconfig.c that caused problems. Reported-by: kernel test robot Fixes: 40caa127f3c7 ("init: bootconfig: Remove all bootconfig data when the init memory is removed") Cc: Steven Rostedt Cc: Mike Rapoport Cc: Andrew Morton Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: Vlastimil Babka Signed-off-by: Linus Torvalds

bootconfig: Rename xbc_node_find_child() to xbc_node_find_subkey()

2021-09-09T23:14:33+00:00

Rename xbc_node_find_child() to xbc_node_find_subkey() for clarifying that function returns a key node (no value node). Since there are xbc_node_for_each_child() (loop on all child nodes) and xbc_node_for_each_subkey() (loop on only subkey nodes), this name distinction is necessary to avoid confusing users. Link: https://lkml.kernel.org/r/163119459826.161018.11200274779483115300.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware)

bootconfig: Support mixing a value and subkeys under a key

2021-06-10T17:41:26+00:00

Support mixing a value and subkeys under a key. Since kernel cmdline options will support "aaa.bbb=value1 aaa.bbb.ccc=value2", it is better that the bootconfig supports such configuration too. Note that this does not change syntax itself but just accepts mixed value and subkeys e.g. key = value1 key.subkey = value2 But this is not accepted; key { value1 subkey = value2 } That will make value1 as a subkey. Also, the order of the value node under a key is fixed. If there are a value and subkeys, the value is always the first child node of the key. Thus if user specifies subkeys first, e.g. key.subkey = value1 key = value2 In the program (and /proc/bootconfig), it will be shown as below key = value2 key.subkey = value1 Link: https://lkml.kernel.org/r/162262194685.264090.7738574774030567419.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware)

bootconfig: Change array value to use child node

2021-06-10T17:38:25+00:00

It is not possible to put an array value with subkeys under a key node, because both of subkeys and the array elements are using "next" field of the xbc_node. Thus this changes the array values to use "child" field in the array case. The reason why split this change is to test it easily. Link: https://lkml.kernel.org/r/162262193838.264090.16044473274501498656.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware)