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@xxxxxxxxxx>
Fixes: 9aa1206e8f48 ("bpf: Add redirect_peer helper")
Cc: stable@xxxxxxxxxxxxxxx
---
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).