linux-kernel - Re: [PATCHv6 04/13] kexec_file: Use bpf-prog to decompose image

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <7509e4d1cd0a1a8a0f2b1a33c8a1f503e7275c826f9fc138e8cb2f12c4add8ec@mail.kernel.org>
Date: Mon, 19 Jan 2026 18:45:41 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: piliu@...hat.com,kexec@...ts.infradead.org
Cc: piliu@...hat.com,davem@...emloft.net,ast@...nel.org,daniel@...earbox.net,john.fastabend@...il.com,andrii@...nel.org,martin.lau@...ux.dev,eddyz87@...il.com,song@...nel.org,yonghong.song@...ux.dev,jeremy.linton@....com,catalin.marinas@....com,will@...nel.org,ardb@...nel.org,horms@...nel.org,kraxel@...hat.com,vkuznets@...hat.com,prudo@...hat.com,vmalik@...hat.com,kernel@...rr.cc,bhe@...hat.com,dyoung@...hat.com,akpm@...ux-foundation.org,bpf@...r.kernel.org,systemd-devel@...ts.freedesktop.org,linux-kernel@...r.kernel.org,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCHv6 04/13] kexec_file: Use bpf-prog to decompose image

> diff --git a/kernel/kexec_bpf_loader.c b/kernel/kexec_bpf_loader.c
> new file mode 100644
> index 000000000000..dc59e1389da9
> --- /dev/null
> +++ b/kernel/kexec_bpf_loader.c

[ ... ]

> +struct kexec_context {
> +	bool kdump;
> +	char *kernel;
> +	int kernel_sz;
> +	char *initrd;
> +	int initrd_sz;
> +	char *cmdline;
> +	int cmdline_sz;
> +};

The *_sz fields here are int, but image->kernel_buf_len and related fields
are unsigned long. Could this cause truncation issues for buffers larger
than INT_MAX?

[ ... ]

> +int decompose_kexec_image(struct kimage *image, int extended_fd)
> +{
> +	struct kexec_context context = { 0 };
> +	struct bpf_parser_context *bpf;
> +	unsigned long kernel_sz, bpf_sz;
> +	char *kernel_start, *bpf_start;
> +	int ret = 0;
> +
> +	if (image->type != KEXEC_TYPE_CRASH)
> +	        context.kdump = false;
> +	else
> +	        context.kdump = true;
> +
> +	kernel_start = image->kernel_buf;
> +	kernel_sz = image->kernel_buf_len;
> +
> +	while (file_has_bpf_section(kernel_start, kernel_sz)) {

With the placeholder arm_bpf_prog/disarm_bpf_prog functions that do nothing,
if an image has a .bpf section, won't this loop iterate forever? The BPF
program is supposed to modify context.kernel to point to the inner content,
but without a real implementation, context.kernel stays unchanged after
kexec_image_parser_anchor() returns.

Note: commit 59dbdff4e55b ("kexec_file: Integrate bpf light skeleton to load
image with bpf-prog") later in the series fills in these placeholders.

> +		bpf = alloc_bpf_parser_context(kexec_buff_parser, &context);
> +		if (!bpf)
> +			return -ENOMEM;

[ ... ]

> +		kernel_start = context.kernel;
> +		kernel_sz = context.kernel_sz;
> +
> +		/*
> +		 * detach the current bpf-prog from their attachment points.
> +		 */
> +		disarm_bpf_prog();
> +		put_bpf_parser_context(bpf);
> +	}
> +
> +	/*
> +	 * image's kernel_buf, initrd_buf, cmdline_buf are set. Now they should
> +	 * be updated to the new content.
> +	 */
> +	image->kernel_buf = context.kernel;
> +	image->kernel_buf_len = context.kernel_sz;
> +	image->initrd_buf = context.initrd;
> +	image->initrd_buf_len = context.initrd_sz;
> +	image->cmdline_buf = context.cmdline;
> +	image->cmdline_buf_len = context.cmdline_sz;

When the kernel image has no .bpf section, the while loop never executes.
In that case, context.kernel remains NULL (from the zero initializer), and
these lines set image->kernel_buf = NULL, image->kernel_buf_len = 0.

This appears to leak the original image->kernel_buf that was allocated by
kernel_read_file_from_fd() in kimage_file_prepare_segments(). The subsequent
arch_kexec_kernel_image_probe() call then receives NULL instead of the valid
kernel buffer.

Should there be a check to preserve the original buffers when no
decomposition occurred?

> +
> +	return 0;

[ ... ]

> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 0222d17072d4..f9674bb5bd8d 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -238,7 +238,14 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
>  		goto out;
>  #endif
>
> +	if (IS_ENABLED(CONFIG_KEXEC_BPF))
> +		decompose_kexec_image(image, initrd_fd);

The return value of decompose_kexec_image() is ignored here. If it returns
an error (e.g., -ENOMEM from alloc_bpf_parser_context()), the function
continues with potentially corrupted state instead of propagating the error.

Should this check the return value and goto out on failure?

> +
> +	/*
> +	 * From this point, the kexec subsystem handle the kernel boot protocol.
> +	 *
> +	 * Call arch image probe handlers
> +	 */
>  	ret = arch_kexec_kernel_image_probe(image, image->kernel_buf,
>  					    image->kernel_buf_len);


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21147860407