From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: sashiko-bot@kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] tools/bootconfig: Consolidate xbc_init() to error message wrapper
Date: Thu, 10 Sep 2026 09:07:29 +0900 [thread overview]
Message-ID: <20260910090729.d18eb065753da71daccefb3f@kernel.org> (raw)
In-Reply-To: <20260909161113.16C691F00A3A@smtp.kernel.org>
On Wed, 09 Sep 2026 16:11:12 +0000
sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Integer overflow in initrd bootconfig size calculation leading to a heap buffer overflow.
> --
>
> commit 51beb61f7aa059b732b7d7560c90f8155150ccd7
> Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> tools/bootconfig: Consolidate xbc_init() to error message wrapper
>
> Use init_xbc_with_error() for all bootconfig initialization in the
> bootconfig tool instead of showing errors in different way.
>
> This simplifies the code logic and make it easy to maintain.
>
> > diff --git a/tools/bootconfig/main.c b/tools/bootconfig/main.c
> > index 6035404733c38..7117aa9b2a839 100644
> > --- a/tools/bootconfig/main.c
> > +++ b/tools/bootconfig/main.c
> [ ... ]
> > @@ -238,52 +278,9 @@ static int load_xbc_from_initrd(int fd, char **buf)
> > return -EINVAL;
> > }
> >
> > - ret = xbc_init(*buf, size, &msg, NULL);
> > - /* Wrong data */
> > - if (ret < 0) {
> > - pr_err("parse error: %s.\n", msg);
> > - return ret;
> > - }
> > + ret = init_xbc_with_error(*buf, size);
>
> [Severity: High]
> This is a pre-existing issue, but is it possible for a 32-bit integer overflow
> to bypass the size validation check in load_xbc_from_initrd()?
Oh, I never thought I could shoot myself in the foot like that.
Anyway, since bootconfig file size should be smaller than 32KB,
so we can check the file size before opening it.
>
> In load_xbc_from_initrd(), size is read from the file as a uint32_t:
>
> tools/bootconfig/main.c:load_xbc_from_initrd() {
> ...
> if (read(fd, &size, sizeof(uint32_t)) < 0)
> return pr_errno("Failed to read size", -errno);
> size = le32toh(size);
> ...
> if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) {
> pr_err("bootconfig size is too big\n");
> return -E2BIG;
> }
> ...
> }
>
> On 32-bit systems, if an attacker crafts size such that adding
> BOOTCONFIG_FOOTER_SIZE (20) wraps around (for instance, if size is 0xFFFFFFFF),
> the stat.st_size < size + BOOTCONFIG_FOOTER_SIZE check can be bypassed.
>
> This would lead to load_xbc_fd() being called with size evaluating to -1:
>
> tools/bootconfig/main.c:load_xbc_fd() {
> ...
> *buf = malloc(size + 1);
> if (!*buf)
> return -ENOMEM;
>
> ret = read(fd, *buf, size);
> if (ret < 0)
> return -errno;
> (*buf)[size] = '\0';
> ...
> }
>
> The malloc(size + 1) would result in a 0-byte allocation, while the
> read(fd, *buf, size) would cast the negative size to size_t (0xFFFFFFFF) and
> overflow the chunk. Finally, (*buf)[size] = '\0' would write to a negative
> index (-1), which corrupts heap metadata.
Good catch!
>
> Could we make this size check more robust against integer overflow?
OK, let me fix it too.
Thanks!
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-09-10 0:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 15:53 [PATCH 0/3] bootconfig: Reject unexpected data after null character and cleanups Masami Hiramatsu (Google)
2026-09-09 15:53 ` [PATCH 1/3] bootconfig: Reject unexpected data after null character Masami Hiramatsu (Google)
2026-09-10 5:29 ` Sang-Heon Jeon
2026-09-09 15:53 ` [PATCH 2/3] tools/bootconfig: Consolidate xbc_init() to error message wrapper Masami Hiramatsu (Google)
2026-09-09 16:11 ` sashiko-bot
2026-09-10 0:07 ` Masami Hiramatsu [this message]
2026-09-10 5:30 ` Sang-Heon Jeon
2026-09-10 14:36 ` Masami Hiramatsu
2026-09-09 15:54 ` [PATCH 3/3] bootconfig: Skip internal tree sanity checks in kernel Masami Hiramatsu (Google)
2026-09-10 5:30 ` Sang-Heon Jeon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260910090729.d18eb065753da71daccefb3f@kernel.org \
--to=mhiramat@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-bot@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).