[PATCH bpf 0/2] bpf: prevent offloaded programs from running on host via tcx/netkit

[PATCH bpf 0/2] bpf: prevent offloaded programs from running on host via tcx/netkit

[Jiayuan Chen]

Yinhao reported a splat [1] when attaching a BPF program loaded with
prog_ifindex (targeted at an offload-capable device such as netdevsim)
to the software path via BPF_TCX_EGRESS. The program's bpf_func had
already been replaced by bpf_prog_warn_on_exec() during offload compile,
so the first packet that reaches tcx_run() trips the WARN:

[   19.592982] ------------[ cut here ]------------
[   19.594654] attempt to execute device eBPF program on the host!
[   19.594659] WARNING: kernel/bpf/offload.c:420 at 0x0, CPU#0: poc/337
[   19.599906] Modules linked in:
[   19.600680] CPU: 0 UID: 0 PID: 337 Comm: poc Not tainted
6.18.0-rc7-next-20251125 #10 PREEMPT(none)
[   19.601659] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   19.602684] RIP: 0010:bpf_prog_warn_on_exec+0xc/0x20
[   19.603241] Code: 28 00 48 89 ef e8 74 44 2f 00 eb d7 66 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8d 3d a4 eb 95
06 <67> 48 0f b9 3a 31 c0 e9 83 76 44 ff 0f 1f 84 00 00 00 00 00 90 90
[   19.605093] RSP: 0018:ffff8881066e73d8 EFLAGS: 00010246
[   19.605663] RAX: ffffffff81cbca70 RBX: ffff8881013c4210 RCX:
0000000000000004
[   19.606378] RDX: 1ffff11020278842 RSI: ffffc90000563060 RDI:
ffffffff8861b620
[   19.607107] RBP: ffff8881010d0640 R08: ffff8881013c4210 R09:
ffff8881010d06b0
[   19.607827] R10: ffff8881010d06c3 R11: ffffc90000563000 R12:
ffffc90000563000
[   19.608751] R13: ffff8881010d06b4 R14: ffff888115eb1a34 R15:
dffffc0000000000
[   19.609478] FS:  000000000294c380(0000) GS:ffff8881911e9000(0000)
knlGS:0000000000000000
[   19.610316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   19.610943] CR2: 000057f6b9eb38c0 CR3: 00000001010ea000 CR4:
0000000000750ef0
[   19.611712] PKRU: 55555554
[   19.612006] Call Trace:
[   19.612281]  <TASK>
[   19.612523]  __dev_queue_xmit+0x22cb/0x3530
[   19.617607]  ip_finish_output2+0x621/0x1a60
[   19.621371]  ip_output+0x170/0x2e0
[   19.624586]  ip_send_skb+0x129/0x180
[   19.624940]  udp_send_skb+0x65d/0x1300
[   19.625316]  udp_sendmsg+0x13bf/0x2000
[   19.629960]  __sys_sendto+0x396/0x470
[   19.633720]  __x64_sys_sendto+0xdc/0x1b0
[   19.635066]  do_syscall_64+0x76/0x10a0
[   19.641701]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   19.642240] RIP: 0033:0x4240d7
[   19.642597] Code: 00 89 01 e9 c1 fe ff ff e8 f6 03 00 00 66 0f 1f 44
00 00 f3 0f 1e fa 80 3d 8d 3f 09 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0
[   19.646088] RSP: 002b:00007fffcb9ecb68 EFLAGS: 00000202 ORIG_RAX:
000000000000002c
[   19.648938] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
00000000004240d7
[   19.652116] RDX: 0000000000000008 RSI: 00007fffcb9ecce0 RDI:
0000000000000005
[   19.653148] RBP: 00007fffcb9eccf0 R08: 00007fffcb9ecbb0 R09:
0000000000000010
[   19.653951] R10: 0000000000000000 R11: 0000000000000202 R12:
00007fffcb9ece08
[   19.654760] R13: 00007fffcb9ece18 R14: 00000000004b2868 R15:
0000000000000001
[   19.657462]  </TASK>
[   19.657703] ---[ end trace 0000000000000000 ]---

The reason is that tcx and netkit never checked for offloaded programs
on attach, unlike XDP which already rejects this in dev_xdp_attach().
This series adds the same guard to both so offloaded programs can't be
attached to the software path.

[1]: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/

Jiayuan Chen (2):
  bpf, tcx: reject offloaded programs on attach
  bpf, netkit: reject offloaded programs on attach

 drivers/net/netkit.c | 6 ++++++
 kernel/bpf/tcx.c     | 6 ++++++
 2 files changed, 12 insertions(+)

-- 
2.43.0

[PATCH bpf 1/2] bpf, tcx: reject offloaded programs on attach

[Jiayuan Chen]

An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
since it's supposed to run on the NIC, not the host. But tcx doesn't
check this and happily attaches it to the software path, so the first
packet hits the WARN.

XDP already guards this in dev_xdp_attach(); tcx just never got the
same check. Add it to both tcx_prog_attach() and tcx_link_attach().

Use bpf_prog_is_offloaded() instead of bpf_prog_is_dev_bound() so that
dev-bound-only programs (still JITed for host) keep working.

Fixes: e420bed025071 ("bpf: Add fd-based tcx multi-prog infra with link support")
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
Closes: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 kernel/bpf/tcx.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
index 02db0113b8e7c..86f4636d5a677 100644
--- a/kernel/bpf/tcx.c
+++ b/kernel/bpf/tcx.c
@@ -16,6 +16,9 @@ int tcx_prog_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;
+
 	rtnl_lock();
 	dev = __dev_get_by_index(net, attr->target_ifindex);
 	if (!dev) {
@@ -315,6 +318,9 @@ int tcx_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
 	struct tcx_link *tcx;
 	int ret;
 
+	if (bpf_prog_is_offloaded(prog->aux))
+		return -EINVAL;
+
 	rtnl_lock();
 	dev = __dev_get_by_index(net, attr->link_create.target_ifindex);
 	if (!dev) {
-- 
2.43.0

[PATCH bpf 2/2] bpf, netkit: reject offloaded programs on attach

[Jiayuan Chen]

Same issue as the tcx fix: netkit accepts SCHED_CLS programs but never
checks if they were loaded for hardware offload. If someone loads a
program with prog_ifindex pointing to an offload-capable device and then
attaches it to a netkit peer, the bpf_func is bpf_prog_warn_on_exec()
and the first packet triggers the WARN.

Reject offloaded programs in both netkit_prog_attach() and
netkit_link_attach().

Fixes: 35dfaad7188cd ("netkit, bpf: Add bpf programmable net device")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 drivers/net/netkit.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index 5c0e01396e064..c4f764034c90f 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -533,6 +533,9 @@ int netkit_prog_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;
+
 	rtnl_lock();
 	dev = netkit_dev_fetch(current->nsproxy->net_ns, attr->target_ifindex,
 			       attr->attach_type);
@@ -788,6 +791,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;
+
 	rtnl_lock();
 	dev = netkit_dev_fetch(current->nsproxy->net_ns,
 			       attr->link_create.target_ifindex,
-- 
2.43.0

Re: [PATCH bpf 1/2] bpf, tcx: reject offloaded programs on attach

[sashiko-bot]

Sashiko AI review found 2 potential issue(s):
- [High] Incomplete fix: Offloaded programs can still be attached to software paths via BPF_LINK_UPDATE
- [High] Missing device-bound validation in TCX and Netkit attach paths
--

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

bpf, tcx: reject offloaded programs on attach
    
An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
since it's supposed to run on the NIC, not the host. But tcx doesn't
check this and happily attaches it to the software path, so the first
packet hits the WARN.

Closes: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/

> diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
> index 02db0113b8e7c..86f4636d5a677 100644
> --- a/kernel/bpf/tcx.c
> +++ b/kernel/bpf/tcx.c
> @@ -16,6 +16,9 @@ int tcx_prog_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;
> +

The commit message mentions using bpf_prog_is_offloaded() instead of
bpf_prog_is_dev_bound() so that dev-bound-only programs keep working for TCX
and Netkit.

XDP validates device matching in dev_xdp_attach():

    if (bpf_prog_is_dev_bound(new_prog->aux) &&
        !bpf_offload_dev_match(new_prog, dev)) {
        ...
    }

The kernel relies on attach-time validation to guarantee safety for hardware
metadata kfuncs, as documented in bpf_dev_bound_resolve_kfunc():

"We rely on bpf_dev_bound_match() check at attach to render this program
unusable"

If a program is device-bound, shouldn't we still verify it is being attached
to the correct device?

Without a similar bpf_offload_dev_match() check here in the TCX and Netkit
attach paths, could a user attach a program bound to device A onto device B?

Could this cause driver-specific kfuncs to execute on device B's SKBs while
blindly assuming device A's internal data layout, leading to out-of-bounds
memory accesses and kernel panics?

>  	rtnl_lock();
>  	dev = __dev_get_by_index(net, attr->target_ifindex);

[ ... ]

> @@ -315,6 +318,9 @@ int tcx_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
>  	struct tcx_link *tcx;
>  	int ret;
>  
> +	if (bpf_prog_is_offloaded(prog->aux))
> +		return -EINVAL;
> +

While this prevents offloaded programs from being attached initially, do
we need to protect the link update paths against this regression as well?

It appears tcx_link_update() and netkit_link_update() pass the new program
directly to bpf_mprog_attach() without validating its offload status:

kernel/bpf/tcx.c:tcx_link_update() {
    ...
    ret = bpf_mprog_attach(entry, &entry_new, nprog, oprog, NULL,
                           link->flags, 0, 0);
    ...
}

If a user creates a valid link with a standard program, could they use
BPF_LINK_UPDATE to replace it with an offloaded program?

Similarly, does bpf_xdp_link_update() lack the bpf_prog_is_offloaded() check
present in dev_xdp_attach(), allowing it to install an offloaded program into
an SKB or native mode XDP link?

If an offloaded program is attached via these update paths, its bpf_func is
replaced by bpf_prog_warn_on_exec().

Would executing this on the host datapath trigger the WARN(1) panic this
patch intended to fix, potentially allowing a local DoS if panic_on_warn
is set?

>  	rtnl_lock();
>  	dev = __dev_get_by_index(net, attr->link_create.target_ifindex);

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

Re: [PATCH bpf 2/2] bpf, netkit: reject offloaded programs on attach

[sashiko-bot]

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

Re: [PATCH bpf 2/2] bpf, netkit: reject offloaded programs on attach

[Jiayuan Chen]

On 4/24/26 11:37 AM, sashiko-bot@kernel.org wrote:
> 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.
>

You're right, will fix netkit_link_update() in v2.


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

Re: [PATCH bpf 1/2] bpf, tcx: reject offloaded programs on attach

[Jiayuan Chen]

On 4/24/26 11:37 AM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 2 potential issue(s):
> - [High] Incomplete fix: Offloaded programs can still be attached to software paths via BPF_LINK_UPDATE
> - [High] Missing device-bound validation in TCX and Netkit attach paths
> --
>
> commit ea2bbf8a59b47b06842fc8c920b0debcc1bed553
> Author: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> bpf, tcx: reject offloaded programs on attach
>      
> An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
> since it's supposed to run on the NIC, not the host. But tcx doesn't
> check this and happily attaches it to the software path, so the first
> packet hits the WARN.
>
> Closes: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
>
>> diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
>> index 02db0113b8e7c..86f4636d5a677 100644
>> --- a/kernel/bpf/tcx.c
>> +++ b/kernel/bpf/tcx.c
>> @@ -16,6 +16,9 @@ int tcx_prog_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;
>> +
> The commit message mentions using bpf_prog_is_offloaded() instead of
> bpf_prog_is_dev_bound() so that dev-bound-only programs keep working for TCX
> and Netkit.
>
> XDP validates device matching in dev_xdp_attach():
>
>      if (bpf_prog_is_dev_bound(new_prog->aux) &&
>          !bpf_offload_dev_match(new_prog, dev)) {
>          ...
>      }
>
> The kernel relies on attach-time validation to guarantee safety for hardware
> metadata kfuncs, as documented in bpf_dev_bound_resolve_kfunc():
>
> "We rely on bpf_dev_bound_match() check at attach to render this program
> unusable"
>
> If a program is device-bound, shouldn't we still verify it is being attached
> to the correct device?
>
> Without a similar bpf_offload_dev_match() check here in the TCX and Netkit
> attach paths, could a user attach a program bound to device A onto device B?
>
> Could this cause driver-specific kfuncs to execute on device B's SKBs while
> blindly assuming device A's internal data layout, leading to out-of-bounds
> memory accesses and kernel panics?


On bpf_offload_dev_match(): SCHED_CLS doesn't allow dev-bound-only 
(rejected in bpf_prog_dev_bound_init()),

so bpf_prog_is_offloaded() already covers every case: A program offloaded
to device A attached to device B is rejected unconditionally.

>>   	rtnl_lock();
>>   	dev = __dev_get_by_index(net, attr->target_ifindex);
> [ ... ]
>
>> @@ -315,6 +318,9 @@ int tcx_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
>>   	struct tcx_link *tcx;
>>   	int ret;
>>   
>> +	if (bpf_prog_is_offloaded(prog->aux))
>> +		return -EINVAL;
>> +
> While this prevents offloaded programs from being attached initially, do
> we need to protect the link update paths against this regression as well?
>
> It appears tcx_link_update() and netkit_link_update() pass the new program
> directly to bpf_mprog_attach() without validating its offload status:
>
> kernel/bpf/tcx.c:tcx_link_update() {
>      ...
>      ret = bpf_mprog_attach(entry, &entry_new, nprog, oprog, NULL,
>                             link->flags, 0, 0);
>      ...
> }
>
> If a user creates a valid link with a standard program, could they use
> BPF_LINK_UPDATE to replace it with an offloaded program?
You're right about the update path — will fix in v2.
> Similarly, does bpf_xdp_link_update() lack the bpf_prog_is_offloaded() check
> present in dev_xdp_attach(), allowing it to install an offloaded program into
> an SKB or native mode XDP link?
>
> If an offloaded program is attached via these update paths, its bpf_func is
> replaced by bpf_prog_warn_on_exec().
>
> Would executing this on the host datapath trigger the WARN(1) panic this
> patch intended to fix, potentially allowing a local DoS if panic_on_warn
> is set?

The same hole exists on the XDP side (bpf_xdp_link_update() bypasses 
dev_xdp_attach()'s offload check); I'll send a separate patch for that.


>>   	rtnl_lock();
>>   	dev = __dev_get_by_index(net, attr->link_create.target_ifindex);