CVE-2026-68441: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Handle TCACTREDIRECT from qdisc filter chains

When a TC filter attached to a qdisc filter chain returns TCACTREDIRECT (ex: via an eBPF program calling bpfredirect() or an actbpf action), the redirect was silently lost i.e no qdisc classify function handled TCACTREDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected.

This has been broken since bpfredirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpfredirect() helper"). We got lucky for a long time because bpfnetcontext was a per-CPU variable that was always available.

commit 401cb7dae813 ("net: Reference bpfredirectinfo via taskstruct on PREEMPTRT.") turned bpfnetcontext into a taskstruct member that is only set up by explicit callers. Without a caller setting it up, bpfredirect() itself crashes with a NULL pointer dereference in bpfnetctxgetri(). However, even with bpfnetcontext available, TCACTREDIRECT from qdisc filter chains cannot be honored without adding skbdoredirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs.

Instead, add a tcfclassifyqdisc() inline helper in pktcls.h, as a wrapper around tcfclassify() for use by qdisc classify functions and tcfqeventhandle(). When the classify verdict is TCACTREDIRECT, the wrapper converts it to TCACTSHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working.

The clsact fast path, tcrun() continues to call tcfclassify() directly and is unaffected: TCACTREDIRECT is returned as-is and handled by schhandleegress/ingress() calling skbdoredirect() as before.