All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: "dzm91@hust.edu.cn" <dzm91@hust.edu.cn>,
	M202472210@hust.edu.cn, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, eddyz87@gmail.com, song@kernel.org,
	yonghong.song@linux.dev, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
	jolsa@kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	hust-os-kernel-patches@googlegroups.com, netdev@vger.kernel.org,
	bpf@vger.kernel.org,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	Yinhao Hu <dddddd@hust.edu.cn>
Subject: Re: bpf: xdp: unhandled error in xdp_test_run_init_page() leads to crash
Date: Thu, 18 Dec 2025 10:26:14 -0800	[thread overview]
Message-ID: <d0a58c79-eb85-41d2-bc17-7b507f57155a@linux.dev> (raw)
In-Reply-To: <fa2be179-bad7-4ee3-8668-4903d1853461@hust.edu.cn>


On 12/18/25 2:43 AM, Yinhao Hu wrote:
> Our fuzzer tool discovered a user-memory-access vulnerability in the BPF
> subsystem. The vulnerability is triggered when building an `sk_buff`
> from an XDP frame that has not been properly initialized due to an
> unhandled initialization failure, causing the kernel to access an
> invalid memory address.
> 
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
> 
> ## Root Cause
> 
> `xdp_test_run_setup()` attempts to create a `page_pool` with the page
> initialization callback `xdp_test_run_init_page()`.
> 
> During page initialization, `xdp_test_run_init_page()` calls
> `xdp_update_frame_from_buff()` to initialize an `xdp_frame`. However, if
> the available headroom in the associated `xdp_buff` is insufficient,
> `xdp_update_frame_from_buff()` returns an error. This error is not
> handled by `xdp_test_run_init_page()`, leaving the `xdp_frame`
> uninitialized.
> 
> Later, `xdp_test_run_batch()` retrieves this `xdp_frame` from the
> `page_pool`. Although it may attempt to partially reinitialize the frame
> via `reset_ctx()`, the failure from `xdp_update_frame_from_buff()` is
> still ignored.
> 
> Finally, `__xdp_build_skb_from_frame()` attempts to construct an
> `sk_buff` from the uninitialized `xdp_frame`. It reads uninitialized
> members (e.g., `data`, `headroom`, `frame_sz`) to compute a `hard_start`
> address, which is then passed to `build_skb_around()`. The underlying
> `__build_skb_around()` attempts to write to this invalid address,
> resulting in a kernel crash.
> 
> ## Execution Flow Visualization
> 
> ```
> Vulnerability Execution Flow
> |
> |--- 1. An XDP program is loaded with act XDP_PASS
> |
> |--- 2. `bpf(BPF_PROG_TEST_RUN, ...)` Syscall Execution
> |    |
> |    `-- bpf_test_run_xdp_live
> |        |
> |        `-- xdp_test_run_setup
> |        |   |
> |        |   `--> page_pool_create() with init callback
> xdp_test_run_init_page()
> |        |         |
> |        |         `--> xdp_update_frame_from_buff() may fail, but error
> is ignored, leaving xdp_frame uninitialized
> |        |
> |        `-- xdp_test_run_batch
> |             |
> |             |--> page_pool_dev_alloc_pages() returns page with
> uninitialized xdp_frame
> |             |
> |             `--> xdp_recv_frames
> |                   |
> |                   |--> __xdp_build_skb_from_frame() reads
> uninitialized xdpf members, computes invalid hard_start address, passes
> it to build_skb_around()
> |                   |
> |                   `--> __build_skb_around() writes to invalid address
> -> CRASH
> ```
> 

This looks a legit issue. Toke, please help to take a look.


  reply	other threads:[~2025-12-18 18:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 10:43 bpf: xdp: unhandled error in xdp_test_run_init_page() leads to crash Yinhao Hu
2025-12-18 18:26 ` Martin KaFai Lau [this message]
2026-01-04 16:23 ` [PATCH bpf-next 0/2] bpf, test_run: Fix user-memory-access vulnerability for LIVE_FRAMES KaFai Wan
2026-01-04 16:23   ` [PATCH bpf-next 1/2] " KaFai Wan
2026-01-05 10:46     ` Toke Høiland-Jørgensen
2026-01-05 13:22       ` KaFai Wan
2026-01-05 16:43         ` Toke Høiland-Jørgensen
2026-01-06 13:53           ` KaFai Wan
2026-01-04 16:23   ` [PATCH bpf-next 2/2] selftests/bpf: Add test for xdp_md context with LIVE_FRAMES in BPF_PROG_TEST_RUN KaFai Wan
2026-01-05  8:07   ` [syzbot ci] Re: bpf, test_run: Fix user-memory-access vulnerability for LIVE_FRAMES syzbot 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=d0a58c79-eb85-41d2-bc17-7b507f57155a@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=M202472210@hust.edu.cn \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dddddd@hust.edu.cn \
    --cc=dzm91@hust.edu.cn \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=horms@kernel.org \
    --cc=hust-os-kernel-patches@googlegroups.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=toke@redhat.com \
    --cc=yonghong.song@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.