All of lore.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 v2 3/3] bpf, xdp: reject offloaded programs on link update
Date: Sat, 25 Apr 2026 10:44:35 +0000	[thread overview]
Message-ID: <20260425104435.ED443C2BCB5@smtp.kernel.org> (raw)
In-Reply-To: <20260424104201.217604-4-jiayuan.chen@linux.dev>

Sashiko AI review found 1 potential issue(s):
- [Critical] Incomplete validation mirroring in `bpf_xdp_link_update()` allows device-bound programs to bypass security checks, leading to type confusion and memory corruption.
--

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

bpf, xdp: reject offloaded programs on link update

This commit mirrors the offload check from dev_xdp_attach to
bpf_xdp_link_update to reject offloaded programs when the link is not in
HW mode. This prevents a user from replacing a regular XDP link with an
offloaded program via BPF_LINK_UPDATE.

> diff --git a/net/core/dev.c b/net/core/dev.c
> --- a/net/core/dev.c
> +++ b/net/core/dev.c

[ ... ]

> @@ -10678,6 +10678,11 @@ static int bpf_xdp_link_update(struct bpf_link *link, struct bpf_prog *new_prog,
>  
>  	netdev_lock_ops(xdp_link->dev);
>  	mode = dev_xdp_mode(xdp_link->dev, xdp_link->flags);
> +	if (mode != XDP_MODE_HW && bpf_prog_is_offloaded(new_prog->aux)) {

Does this check omit the dev_bound validations that are already present in
dev_xdp_attach?

If a program is loaded with BPF_F_XDP_DEV_BOUND_ONLY, it has dev_bound set
to true but offload_requested set to false, meaning bpf_prog_is_offloaded
will return false. Could such a program bypass this check and be attached
to an SKB-mode link, potentially causing the generic XDP runner to execute
device-specific kfuncs that cast the generic xdp_md context to
driver-specific structures?

Additionally, if the link is in HW mode, this condition evaluates to false
and the validation is skipped. Does this allow a program offloaded to a
different device to be attached to an HW link on the current device? If so,
the driver might receive XDP_SETUP_PROG_HW and incorrectly cast the new
program's aux->offload->dev_priv to its own internal structure, resulting
in memory corruption.

> +		netdev_unlock_ops(xdp_link->dev);
> +		err = -EINVAL;
> +		goto out_unlock;
> +	}
>  	bpf_op = dev_xdp_bpf_op(xdp_link->dev, mode);
>  	err = dev_xdp_install(xdp_link->dev, mode, bpf_op, NULL,
>  			      xdp_link->flags, new_prog);

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

      reply	other threads:[~2026-04-25 10:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-24 10:41 [PATCH bpf v2 0/3] bpf: prevent offloaded programs from running on host via tcx/netkit Jiayuan Chen
2026-04-24 10:41 ` [PATCH bpf v2 1/3] bpf, tcx: reject offloaded programs on attach Jiayuan Chen
2026-04-24 13:57   ` Alexei Starovoitov
2026-04-25 10:44   ` sashiko-bot
2026-04-24 10:41 ` [PATCH bpf v2 2/3] bpf, netkit: " Jiayuan Chen
2026-04-24 10:41 ` [PATCH bpf v2 3/3] bpf, xdp: reject offloaded programs on link update Jiayuan Chen
2026-04-25 10:44   ` 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=20260425104435.ED443C2BCB5@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 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.