All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Siddharth C" <siddharthcibi@icloud.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects
Date: Sat, 20 Jun 2026 12:31:01 +0000	[thread overview]
Message-ID: <20260620123101.AEC651F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260620121321.45227-2-siddharthcibi@icloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uninitialized `rx_queue_index` in `struct xdp_frame` constructed by the BPF testing framework causes a kernel memory information leak.
--

commit f1285cd92bd58ea552eb0b340894db477870968e
Author: Siddharth C <siddharthcibi@icloud.com>
Date:   Sat Jun 20 12:13:13 2026 +0000

    bpf: preserve rx_queue_index across XDP redirects
    
    Store rx_queue_index in struct xdp_frame during xdp_buff to
    xdp_frame conversion and restore it when rebuilding xdp_rxq_info
    for cpumap and devmap execution paths.
    
    This preserves ingress RX queue information for XDP programs
    executed after redirect, allowing access to the original
    rx_queue_index instead of losing queue context.
    
    Also propagate rx_queue_index for zero-copy XDP frame conversion.
    
    Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>

> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
> index 5e59ab896f058..8f2d7013620f7 100644
> --- a/kernel/bpf/cpumap.c
> +++ b/kernel/bpf/cpumap.c
> @@ -197,7 +197,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
>  
>  		rxq.dev = xdpf->dev_rx;
>  		rxq.mem.type = xdpf->mem_type;
> -		/* TODO: report queue_index to xdp_rxq_info */
> +		rxq.queue_index = xdpf->rx_queue_index;

[Severity: High]
Can this leak uninitialized kernel page memory via ctx->rx_queue_index when
using BPF_PROG_TEST_RUN?

The BPF testing framework uses xdp_update_frame_from_buff() to initialize
mock frames in net/bpf/test_run.c. Because xdp_update_frame_from_buff() 
only copies sizes and pointers, test_run manually copies mem_type but was
not updated by this patch to initialize rx_queue_index:

net/bpf/test_run.c:xdp_test_run_init_page() {
    ...
    xdp_update_frame_from_buff(new_ctx, frm);
    frm->mem_type = new_ctx->rxq->mem.type;
    /* Missing: frm->rx_queue_index = new_ctx->rxq->queue_index; */
    ...
}

It is also missed in the context reset path:

net/bpf/test_run.c:reset_ctx() {
    ...
    xdp_update_frame_from_buff(&head->ctx, head->frame);
    head->frame->mem_type = head->orig_ctx.rxq->mem.type;
    /* Missing: head->frame->rx_queue_index = head->orig_ctx.rxq->queue_index; */
}

If a tested BPF program returns XDP_REDIRECT to a cpumap or devmap, the
map execution reconstructs the xdp_rxq_info using the uninitialized
xdpf->rx_queue_index field. A chained BPF program executing on the map
could then read ctx->rx_queue_index, exposing 4 bytes of uninitialized
kernel page memory.

Should net/bpf/test_run.c be updated to initialize rx_queue_index?

>  
>  		xdp_convert_frame_to_buff(xdpf, &xdp);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260620121321.45227-1-siddharthcibi@icloud.com?part=1

  reply	other threads:[~2026-06-20 12:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-20 12:13 Siddharth C
2026-06-20 12:13 ` [PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects Siddharth C
2026-06-20 12:31   ` sashiko-bot [this message]
2026-06-20 12:13 ` [PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata Siddharth C
2026-06-20 12:36   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-06-19 19:57 Siddharth_Cibi
2026-06-19 19:57 ` [PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects Siddharth_Cibi
2026-06-19 20:14   ` sashiko-bot
2026-06-19 20:50   ` bot+bpf-ci

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=20260620123101.AEC651F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=siddharthcibi@icloud.com \
    /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.