Hi Nat, I am surprised that the change in lcp_router_link_addr() is necessary. If a wireguard tunnel interface is paired with a tun, I would expect that there would not be a hardware address included in an RTM_NEWLINK message since a tun should not have a hardware address and the code at line 298 should cause lcp_router_link_addr() to bail early - https://github.com/FDio/vpp/blob/master/src/plugins/linux-cp/lcp_router.c#L298. Or the code at line 308 - https://github.com/FDio/vpp/blob/master/src/plugins/linux-cp/lcp_router.c#L308 .
Is there a series of vppctl commands or API interactions that I could use to reproduce the problem? What kernel version are you using? We (Netgate) run regression tests of wireguard using linux-cp regularly on the ubuntu 24.04 LTS 6.8 kernel and have not run into the problem before. Maybe newer kernels send a hardware address in RTM_NEWLINK for a tun interface? I can merge the updated patch if needed. I'm just surprised that this is an issue and want to understand why it's breaking for you. Thanks, -Matt On Thu, Mar 19, 2026 at 2:40 PM Nathael Leblanc via lists.fd.io <nleblanc= [email protected]> wrote: > Hello Matthew, > > Thanks for the lightning-fast review! > > We were originally on 24.10 for a good chunk of development (recently > 25.06, thank you for all the IPv6 work!), and the segfault from MAC address > sync on non-Ethernet interfaces on RTM_NEWLINK was present in 24.10. Our > apologies, we did not notice the fact our addition in lcp_interface.c was > redundant due to the check higher in the function (we made this addition to > try to hunt for other potential similar bugs, but did not encounter a fault > here). I've re-submitted the patch with only the new check in lcp_router.c > present. > > Let me know if you have any notes, and all the best, > -Nat > > *Nathael Leblanc* > CEO & Co-Founder, Joust Security > > +1.514.800.8071 | [email protected] > > www.joustsec.com > > > > > On Thu, Mar 19, 2026 at 12:24 PM Matthew Smith via lists.fd.io <mgsmith= > [email protected]> wrote: > >> Hi Nat, >> >> I added a comment to the review. It's not clear to me how you're >> encountering a seg fault. Can you describe a sequence of configuration >> commands that would reproduce this behavior? >> >> There was a patch added by Stanislav Zaikin that first appeared in VPP >> 23.06 which should prevent a seg fault from occurring in the instances that >> you described - >> https://github.com/FDio/vpp/commit/fdf917e8f8dd5abb3f9263c9cb3fd9ce00563b60. >> In lcp_itf_pair_create(), it validates that hw->hw_class_index == >> ethernet_hw_interface_class.index when host_if_type == LCP_ITF_HOST_TAP. >> The check you added to lcp_itf_pair_create() comes after this validation >> has already occurred and is inside an 'if (host_if_type >> != LCP_ITF_HOST_TUN)', which implies that host_if_type == LCP_ITF_HOST_TAP. >> So it seems like it should already be guaranteed that hw->hw_class_index == >> ethernet_hw_interface_class.index at that point. >> >> It seems like the only way you could encounter a seg fault in the spots >> that your patch touches would be if you created a linux-cp interface pair >> for an L3 tunnel interface but used host_if_type LCP_ITF_HOST_TAP instead >> of LCP_ITF_HOST_TUN. That should not have been possible since VPP 23.06. Is >> the problem occurring on an older version of VPP? >> >> Thanks, >> -Matt >> >> >> On Wed, Mar 18, 2026 at 10:52 PM Nathael Leblanc via lists.fd.io >> <[email protected]> wrote: >> >>> Good evening everyone, >>> >>> Could I please request a patch review on >>> https://gerrit.fd.io/r/c/vpp/+/45271 -- I promise it's a short one but >>> a good one! >>> >>> The patch addresses a segmentation fault in the linux-cp plugin that is >>> triggered during routing convergence or IP assignment on strictly-Layer3 >>> tunnel interfaces (e.g., in our use case, WireGuard interfaces). >>> >>> The issue stems from LCP assuming the underlying `vnet_hw_interface_t` >>> possesses an Ethernet hardware class. For L3 interfaces: >>> >>> 1. In `lcp_itf_pair_create`, indexing into >>> `ethernet_main.interfaces` with the tunnel's `hw->hw_instance` leads to >>> type confusion and an out-of-bounds read. >>> 2. In `lcp_router_link_addr`, unconditionally comparing the MAC >>> address results in an invalid memory read and a downstream "Secondary MAC >>> Addresses not supported" panic. >>> >>> The patch adds a hardware class guard (`hw->hw_class_index == >>> ethernet_hw_interface_class.index`) before attempting L2 operations. This >>> bypasses MAC synchronization for non-broadcast/L3 tunnels while preserving >>> normal behavior for standard DPDK, RDMA, AF_PACKET, and Loopback interfaces. >>> >>> Feedback and reviews are appreciated. >>> >>> Thank you, >>> -Nat >>> >>> *Nathael Leblanc* >>> CEO & Co-Founder, Joust Security >>> >>> +1.514.800.8071 | [email protected] >>> >>> www.joustsec.com >>> >>> >>> >>> >>> >>> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26898): https://lists.fd.io/g/vpp-dev/message/26898 Mute This Topic: https://lists.fd.io/mt/118395403/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
