> 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
