On 9/29/24 7:02 PM, Jordan Rife wrote:
It is possible to create cycles using bpf_redirect_peer which lead to an an infinite loop inside __netif_receive_skb_core. The simplest way to illustrate this is by attaching a TC program to the ingress hook on both sides of a veth or netkit device pair which redirects to its own peer, although other cycles are possible. This patch places an upper limit on the number of iterations allowed inside __netif_receive_skb_core to prevent this.
Signed-off-by: Jordan Rife jrife@google.com Fixes: 9aa1206e8f48 ("bpf: Add redirect_peer helper") Cc: stable@vger.kernel.org
net/core/dev.c | 11 +++- net/core/dev.h | 1 + .../selftests/bpf/prog_tests/tc_redirect.c | 51 +++++++++++++++++++ .../selftests/bpf/progs/test_tc_peer.c | 13 +++++ 4 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c index cd479f5f22f6..753f8d27f47c 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -5455,6 +5455,7 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc, struct net_device *orig_dev; bool deliver_exact = false; int ret = NET_RX_DROP;
- int loops = 0; __be16 type;
net_timestamp_check(!READ_ONCE(net_hotdata.tstamp_prequeue), skb); @@ -5521,8 +5522,16 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc, nf_skip_egress(skb, true); skb = sch_handle_ingress(skb, &pt_prev, &ret, orig_dev, &another);
if (another)
if (another) {loops++;
No, as you mentioned, there are plenty of other misconfiguration possibilities in and outside bpf where something can loop in the stack (or where you can lock yourself out e.g. drop-all).