On Wed, May 28, 2025 at 9:17 AM Jiayuan Chen jiayuan.chen@linux.dev wrote:
A previous commit expanded the usage scope of bpf_get_cgroup_classid() to all contexts (see Fixes tag), but this was inappropriate.
First, syzkaller reported a bug [1]. Second, it uses skb as an argument, but its implementation varies across different bpf prog types. For example, in sock_filter and sock_addr, it retrieves the classid from the current context (bpf_get_cgroup_classid_curr_proto) instead of from skb. In tc egress and lwt, it fetches the classid from skb->sk, but in tc ingress, it returns 0.
In summary, the definition of bpf_get_cgroup_classid() is ambiguous and its usage scenarios are limited. It should not be treated as a general-purpose helper. This patch reverts part of the previous commit.
I think it's better to make it generic enough instead of reintroducing a bunch of prog specific proto handlers. See this discussion: https://lore.kernel.org/bpf/20250528020755.33182-1-yangfeng59949@163.com/
pw-bot: cr