返回值为void的XDP类型eBPF程序加载后致网络异常是否正常？

我运行了一段返回值为void的XDP类型eBPF示例代码，在返回前调用了bpf_printk。我原本以为该代码会被eBPF验证器拒绝，但它却成功加载到了内核中，还导致我的网络子系统出现异常，不得不重启机器才能恢复网络功能。请问这种情况是否正常？

系统信息 #

• 内核版本：Linux asus 6.5.0-28-generic #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 14:39:20 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
• 操作系统：Ubuntu 22.04.4 LTS

示例代码 #

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

int counter = 0;

SEC("xdp")
void error_packet_count(void *ctx) {
    bpf_printk("%d", counter);
    counter++;
    return;
}

char LICENSE[] SEC("license") = "Dual BSD/GPL";

回答 #

这种情况加载成功属于内核验证器的疏漏，但网络异常是必然的未定义行为结果，具体原因如下：

1. XDP程序签名要求被绕过
   标准XDP程序必须返回XDP_*系列枚举值（比如XDP_PASS、XDP_DROP），用来告诉内核如何处理当前数据包。你的代码用void作为返回类型，完全不符合XDP的规范，理论上验证器应该直接拒绝。但在你使用的6.5.0-28内核版本中，验证器对返回值的检查可能存在漏洞，导致这类不合规代码意外通过加载。

2. 网络异常源于未定义行为
   当XDP程序返回void时，内核无法获取合法的数据包处理指令，后续网络栈的执行会进入未定义状态——可能导致数据包被无差别丢弃、内核内部状态混乱，甚至触发软锁或崩溃。你遇到的网络子系统异常就是这种未定义行为的典型表现。

3. 全局变量的额外风险
   代码中的counter是普通全局变量，没有用eBPF映射（如BPF_MAP_TYPE_ARRAY）来实现，直接在内核态操作这种变量本身就不符合eBPF规范。虽然这次没被验证器拦截，但这类操作可能引发内存一致性问题，进一步加剧系统故障的概率。

修复建议 #

• 修正XDP程序的返回类型：将函数改为返回int，并在结尾返回合法的XDP_*值，比如return XDP_PASS;让数据包正常进入网络栈。
• 用eBPF映射替代全局变量：创建一个数组类型的映射来存储计数，通过bpf_map_lookup_elem和bpf_map_update_elem操作计数，确保符合内核验证规则。
• 加载前做预检查：使用bpftool prog load命令加载时，会输出更详细的验证日志，提前发现这类不合规问题。

内容的提问来源于stack exchange，提问作者Swarn