vlan_output(): use parents context when calling if_output()

[rew]

Summary

A panic can occur when configuring a vlan on wlan interface - reported here: https://lists.freebsd.org/archives/freebsd-hackers/2022-April/001043.html

It seems the vlan driver is calling ieee80211_output() with the wrong
ifnet context and dereferencing a bad pointer. ieee80211_output() is
getting a struct ifvlan when its expecting a struct ieee80211_vap from
the passed in if_softc.

Looking at vlan_output() in sys/net/if_vlan.c, I wonder if the parents
ifnet context should be used when calling if_output().

The backtrace:

KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00a7c4f760
vpanic() at vpanic+0x17f/frame 0xfffffe00a7c4f7b0
panic() at panic+0x43/frame 0xfffffe00a7c4f810
trap_fatal() at trap_fatal+0x385/frame 0xfffffe00a7c4f870
calltrap() at calltrap+0x8/frame 0xfffffe00a7c4f870
--- trap 0x9, rip = 0xffffffff80daeed8, rsp = 0xfffffe00a7c4f948, rbp = 0xfffffe00a7c4fa50 ---
ieee80211_output() at ieee80211_output+0xf8/frame 0xfffffe00a7c4fa50
arp_ifinit() at arp_ifinit+0x6d/frame 0xfffffe00a7c4fab0
vlan_ioctl() at vlan_ioctl+0x1e2/frame 0xfffffe00a7c4fb10
in_control() at in_control+0x9a8/frame 0xfffffe00a7c4fbb0
ifioctl() at ifioctl+0x7f4/frame 0xfffffe00a7c4fca0
kern_ioctl() at kern_ioctl+0x202/frame 0xfffffe00a7c4fd10
sys_ioctl() at sys_ioctl+0x126/frame 0xfffffe00a7c4fde0
amd64_syscall() at amd64_syscall+0x1a8/frame 0xfffffe00a7c4ff30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00a7c4ff30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80125ebfa, rsp = 0x7fffffffe388, rbp = 0x7fffffffe3d0 ---
KDB: enter: panic
[ thread pid 277 tid 100089 ]
Stopped at      kdb_enter+0x32: movq    $0,0x13e7e23(%rip)
db>

PR: 263505

[kp]

Hmm. This *looks* sane to me, but this patch breaks the if_vlan tests, so clearly I'm missing something. A ping over a vlan interface (on top of epair, in a vnet jail) results in ping: sendto: Invalid argument, and I'm not seeing why at the moment.

[kp]

In D36279#824072, @kp wrote:

Hmm. This *looks* sane to me, but this patch breaks the if_vlan tests, so clearly I'm missing something. A ping over a vlan interface (on top of epair, in a vnet jail) results in ping: sendto: Invalid argument, and I'm not seeing why at the moment.

It looks like what's happening here is that we fail the arp lookup because we're trying to do a lookup on the underlying interface, not the vlan interface.

[rew]

In D36279#824118, @kp wrote:

In D36279#824072, @kp wrote:

Hmm. This *looks* sane to me, but this patch breaks the if_vlan tests, so clearly I'm missing something. A ping over a vlan interface (on top of epair, in a vnet jail) results in ping: sendto: Invalid argument, and I'm not seeing why at the moment.

It looks like what's happening here is that we fail the arp lookup because we're trying to do a lookup on the underlying interface, not the vlan interface.

Thanks, I'll look into it and see if I can figure something out.

[glebius]

This is yet another problem that calls into some kind of generic way of inheriting/overlaying methods from parent interface to a child.