if_vxlan(4): Add checking for nesting of tunnels

[zlei]

Summary

User misconfiguration can introduce tunnel loops, which may lead to
kernel stack overflow. Prevent that by checking nesting levels and
dropping packets to be encapsulated, which is the same with current
practices for existing tunnel implementations.

PR: 278422
MFC after: 1 week

[zlei]

@kp has just made similar fix 59a6666ec91d for if_ovpn.

[kp]

I'm not sure I'd have bothered to make the nesting level configurable, but now that you've done the work it'd be silly to not use it.

It'd also be nice to get a test for this, but it looks like there are no tests at all for vxlan now, so it might be a bit more work than is justified for this issue.

sys/net/if_vxlan.c

440

It's not quite that risky, because if_tunnel_check_nesting() checks if the last tunnel hop was this struct ifnet, so if users configure a loop the packet will be discarded immediately, not when it hits the nesting limit.

We do still need the limit, because users might configure a large number of different nested tunnels, which could still run us out of stack space, but that's harder to do by accident.

[zlei]

sys/net/if_vxlan.c

440

It's not quite that risky, because if_tunnel_check_nesting() checks if the last tunnel hop was this struct ifnet, so if users configure a loop the packet will be discarded immediately, not when it hits the nesting limit.

I rechecked implementation of if_tunnel_check_nesting() and you are right :) Thanks for catching that.

We do still need the limit, because users might configure a large number of different nested tunnels, which could still run us out of stack space, but that's harder to do by accident.

True indeed.

[gshapiro]

Just a quick note that the PR listed on this is incorrect. This fix addresses PR 278394.

[zlei]

In D45197#1031659, @gshapiro wrote:

Just a quick note that the PR listed on this is incorrect. This fix addresses PR 278394.

My bad. Thanks for catching that !