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 2/2] bpf, netkit: reject offloaded programs on attach
Date: Fri, 24 Apr 2026 03:37:51 +0000	[thread overview]
Message-ID: <20260424033752.1F76BC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260423033609.252464-3-jiayuan.chen@linux.dev>

Sashiko AI review found 1 potential issue(s):
- [High] The patch prevents attaching offloaded programs during link creation and program attach, but fails to secure the link update path, allowing a complete bypass of the fix.
--

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

bpf, netkit: reject offloaded programs on attach

This commit rejects offloaded BPF programs in netkit_prog_attach() and
netkit_link_attach() to prevent them from triggering a WARN in
bpf_prog_warn_on_exec() when executed on the software path.

> diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
> index 7b56a7ad7a496..d845a24c5915d 100644
> --- a/drivers/net/netkit.c
> +++ b/drivers/net/netkit.c

[ ... ]

> @@ -1000,6 +1003,9 @@ int netkit_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
>  	struct net_device *dev;
>  	int ret;
>  
> +	if (bpf_prog_is_offloaded(prog->aux))
> +		return -EINVAL;
> +

Is it also necessary to reject offloaded programs in netkit_link_update()?

It looks like a user could bypass this fix by creating a netkit link with a
non-offloaded program, and then using BPF_LINK_UPDATE to replace it with an
offloaded program.

The netkit_link_update() callback directly passes the new program to
bpf_mprog_attach() without checking bpf_prog_is_offloaded():

static int netkit_link_update(struct bpf_link *link, struct bpf_prog *nprog,
			      struct bpf_prog *oprog)
{
	...
	ret = bpf_mprog_attach(entry, &entry_new, nprog, link, oprog,
			       BPF_F_REPLACE | BPF_F_ID,
			       link->prog->aux->id, 0);
	...
}

Note that tcx_link_update() in the earlier tcx fix appears to suffer from
the exact same omission.

>  	rtnl_lock();
>  	dev = netkit_dev_fetch(current->nsproxy->net_ns,
>  			       attr->link_create.target_ifindex,

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

  reply	other threads:[~2026-04-24  3:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23  3:36 [PATCH bpf 0/2] bpf: prevent offloaded programs from running on host via tcx/netkit Jiayuan Chen
2026-04-23  3:36 ` [PATCH bpf 1/2] bpf, tcx: reject offloaded programs on attach Jiayuan Chen
2026-04-24  3:37   ` sashiko-bot
2026-04-24  6:53     ` Jiayuan Chen
2026-04-23  3:36 ` [PATCH bpf 2/2] bpf, netkit: " Jiayuan Chen
2026-04-24  3:37   ` sashiko-bot [this message]
2026-04-24  6:53     ` Jiayuan Chen

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=20260424033752.1F76BC19425@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.