public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiayuan Chen" <jiayuan.chen@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v3 2/2] bpf, xdp: move offload check into dev_xdp_install()
Date: Sun, 26 Apr 2026 11:01:55 +0000	[thread overview]
Message-ID: <20260426110156.EC311C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260425105942.223757-3-jiayuan.chen@linux.dev>

Sashiko AI review found 1 potential issue(s):
- [Critical] The patch moves the `bpf_prog_is_offloaded()` check to `dev_xdp_install()` to prevent bypasses during `BPF_LINK_UPDATE`, but fails to move two other critical validation checks for device-bound programs.
--

commit cdf088cb25c4b4a5606f82c9c927c40199abf2f8
Author: Jiayuan Chen <jiayuan.chen@linux.dev>

bpf, xdp: move offload check into dev_xdp_install()

This commit moves the offload check from dev_xdp_attach() into
dev_xdp_install() so that both the attach path and link update path are
covered. This prevents users from replacing a regular program with an
offloaded program via BPF_LINK_UPDATE, which previously bypassed the check.

> diff --git a/net/core/dev.c b/net/core/dev.c
> index 7f95a7065dcfb..15b32b0db193c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c

[ ... ]

> @@ -10463,10 +10468,6 @@ static int dev_xdp_attach(struct net_device *dev, struct netlink_ext_ack *extack
>  			NL_SET_ERR_MSG(extack, "Native and generic XDP can't be active at the same time");
>  			return -EEXIST;
>  		}
> -		if (!offload && bpf_prog_is_offloaded(new_prog->aux)) {
> -			NL_SET_ERR_MSG(extack, "Using offloaded program without HW_MODE flag is not supported");
> -			return -EINVAL;
> -		}
>  		if (bpf_prog_is_dev_bound(new_prog->aux) && !bpf_offload_dev_match(new_prog, dev)) {
>  			NL_SET_ERR_MSG(extack, "Program bound to different device");
>  			return -EINVAL;

Since bpf_xdp_link_update() directly calls dev_xdp_install() and bypasses
dev_xdp_attach(), are the two device-bound validation checks left behind in
dev_xdp_attach() also bypassed during a link update?

If a user creates a generic XDP link and updates it to swap in a
device-bound program, does the device-bound program run on the wrong device
or in SKB mode?

Could this lead to the hardware-specific metadata kfuncs, which are resolved
at load time to the target driver's implementation, miscasting the context
structure during execution?

Should the bpf_prog_is_dev_bound() checks also be moved to
dev_xdp_install() to prevent this regression?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260425105942.223757-1-jiayuan.chen@linux.dev?part=2

      parent reply	other threads:[~2026-04-26 11:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-25 10:59 [PATCH bpf v3 0/2] bpf: prevent offloaded programs from running on host via tcx/netkit Jiayuan Chen
2026-04-25 10:59 ` [PATCH bpf v3 1/2] bpf, tcx, netkit: reject offloaded programs Jiayuan Chen
2026-04-25 10:59 ` [PATCH bpf v3 2/2] bpf, xdp: move offload check into dev_xdp_install() Jiayuan Chen
2026-04-25 11:30   ` bot+bpf-ci
2026-04-26 11:01   ` sashiko-bot [this message]

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=20260426110156.EC311C2BCAF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jiayuan.chen@linux.dev \
    --cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox