On 29 June 2026 14:41:37 BST, Breno Leitao <[email protected]> wrote:
>On Sun, Jun 28, 2026 at 11:56:16AM +0000, Bradley Morgan wrote:
>> When xbc_snprint_cmdline() is called during the size-probing phase
>> (with buf = NULL and size = 0), the function computes the end pointer
>> as 'buf + size' (NULL + 0) and repeatedly advances the pointer via
>> 'buf += ret'.
>>
>> Under the C standard, performing pointer arithmetic on a NULL pointer is
>> undefined behavior. While harmless inside the kernel, this code is also
>> compiled into the userspace host tool 'tools/bootconfig', where host
>> compilers with UBSan or FORTIFY_SOURCE enabled abort the build when they
>> detect NULL pointer arithmetic.
>>
>> Fix this by tracking the running written length as an integer offset
>> ('len') rather than advancing 'buf' directly. Only perform pointer
>> arithmetic if 'buf' is actually non-NULL.
>>
>> Fixes: 5a643e462323 ("bootconfig: move xbc_snprint_cmdline() to
>lib/bootconfig.c")
>
>Isn't commit 5a643e462323 ("bootconfig: move xbc_snprint_cmdline() to
>lib/bootconfig.c") just a code movement?
Ugh, Geminis bullcrap, you are right. I should've just manually looked
for the fixes tag (as I always do)
>> xbc_node_for_each_key_value(root, knode, val) {
>> @@ -439,10 +437,12 @@ int __init xbc_snprint_cmdline(char *buf, size_t
>size, struct xbc_node *root)
>>
>> vnode = xbc_node_get_child(knode);
>> if (!vnode) {
>> - ret = snprintf(buf, rest(buf, end), "%s ", xbc_namebuf);
>> + ret = snprintf(buf ? buf + len : NULL,
>> + size > len ? size - len : 0,
>
>Why not keeping rest() and updating it, instead of open coding it?
>
>Thanks for the fix.
sure I'll do V2, btw if u didn't read, gemini found and fixed this.
As in fully. :)
>--breno
>
Thanks!
