All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Pu Lehui" <pulehui@huaweicloud.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 8/9] riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free
Date: Sat, 25 Jul 2026 15:57:05 +0000	[thread overview]
Message-ID: <20260725155706.54C5C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260725154915.2488611-9-pulehui@huaweicloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] bpf_jit_free() ignores the error return value of bpf_jit_binary_pack_finalize(), leading to a Use-After-Free and Double Free of the JIT ro_header.
--

--- Patch [8]: [PATCH bpf-next v3 8/9] riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free ---
commit a0a806deebfc4afdceb1a23fa093826ade44c8cf
Author: Pu Lehui <pulehui@huawei.com>

riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free

When CFI is enabled, the actual BPF program entry point is shifted forward
by a CFI preamble. This commit subtracts the CFI offset from prog->bpf_func
in bpf_jit_free() to restore the original JITed allocation address before
freeing it, preventing an invalid memory free.

> diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> index cbfcd287ea166..059db1adeaf8d 100644
> --- a/arch/riscv/net/bpf_jit_core.c
> +++ b/arch/riscv/net/bpf_jit_core.c
> @@ -237,6 +237,7 @@ void bpf_jit_free(struct bpf_prog *prog)
>  			kvfree(jit_data->ctx.offset);
>  			kfree(jit_data);
>  		}
> +		prog->bpf_func = (void *)prog->bpf_func - cfi_get_offset();
>  		hdr = bpf_jit_binary_pack_hdr(prog);
>  		bpf_jit_binary_pack_free(hdr, NULL);

[Severity: High]
This is a pre-existing issue, but does ignoring the return value of
bpf_jit_binary_pack_finalize() (called just prior to this diff snippet)
lead to a use-after-free and double free?

If bpf_jit_binary_pack_finalize() fails, it frees ro_header internally:

kernel/bpf/core.c:bpf_jit_binary_pack_finalize() {
    ...
    if (IS_ERR(ptr)) {
        bpf_prog_pack_free(ro_header, ro_header->size);
        return PTR_ERR(ptr);
    }
    ...
}

Back in bpf_jit_free(), we ignore this failure, extract the same freed
header via bpf_jit_binary_pack_hdr(), and call bpf_jit_binary_pack_free()
which dereferences ro_header->size and frees it again:

kernel/bpf/core.c:bpf_jit_binary_pack_free() {
    u32 size = ro_header->size;

    bpf_prog_pack_free(ro_header, size);
    ...
}

Should bpf_jit_free() check if bpf_jit_binary_pack_finalize() returned
an error before attempting to extract and free the header again?

>  		WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(prog));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725154915.2488611-1-pulehui@huaweicloud.com?part=8

  reply	other threads:[~2026-07-25 15:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 15:49 [PATCH bpf-next v3 0/9] Fixes for bpf_jit_free Pu Lehui
2026-07-25 15:49 ` [PATCH bpf-next v3 1/9] bpf: Extract the bpf_jit_binary_hdr helper Pu Lehui
2026-07-25 15:49 ` [PATCH bpf-next v3 2/9] s390/bpf: Fix memory leak in bpf_jit_free Pu Lehui
2026-07-25 15:49 ` [PATCH bpf-next v3 3/9] parisc: " Pu Lehui
2026-07-25 15:54   ` sashiko-bot
2026-07-25 15:49 ` [PATCH bpf-next v3 4/9] bpf, sparc64: " Pu Lehui
2026-07-25 15:49 ` [PATCH bpf-next v3 5/9] ARC, bpf: " Pu Lehui
2026-07-25 15:49 ` [PATCH bpf-next v3 6/9] bpf, arm64: " Pu Lehui
2026-07-25 16:01   ` sashiko-bot
2026-07-25 15:49 ` [PATCH bpf-next v3 7/9] bpf, arm64: Fix private stack leak when JIT failed Pu Lehui
2026-07-25 15:55   ` sashiko-bot
2026-07-25 15:49 ` [PATCH bpf-next v3 8/9] riscv, bpf: Adjust bpf_func to account for CFI offset in bpf_jit_free Pu Lehui
2026-07-25 15:57   ` sashiko-bot [this message]
2026-07-25 15:49 ` [PATCH bpf-next v3 9/9] bpf: Fix double-free RO header " Pu Lehui

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=20260725155706.54C5C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=pulehui@huaweicloud.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.