On Thu, Sep 10, 2026 at 10:59:24AM +0900, Masami Hiramatsu (Google) wrote: > From: Masami Hiramatsu (Google) <[email protected]> > > Sashiko reported that on 32-bit systems, if an attacker crafts size in > the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around > (for instance, if size is 0xFFFFFFFF), the size check in > load_xbc_from_initrd() can be bypassed: > > if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) { > pr_err("bootconfig size is too big\n"); > return -E2BIG; > } > > Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a > corrupted 32-bit size (e.g. 0xFFFFFFFF) against > stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if > size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size > directly into the 32-bit int size parameter of load_xbc_fd(), truncating > large standalone files (>= 2GB). > > In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1, > resulting in malloc(0), an integer overflow in read(), and an > out-of-bounds null-byte write. > > Fix this by: > 1. Rejecting size > XBC_DATA_MAX or > size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd(). > 2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing > it to load_xbc_fd(). > 3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd(). > > Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") > Cc: [email protected] > Reported-by: Sashiko <[email protected]> > Closes: > https://lore.kernel.org/all/[email protected]/ > Closes: > https://lore.kernel.org/all/[email protected]/ > Assisted-by: Antigravity:gemini-3.8-flash > Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
Reviewed-by: Breno Leitao <[email protected]>
