Hello Matthew, Absolutely, I think original build artifacts on this are purged, but let me see if I can just re-run it without our patch applied to get you the full trail resulting in this condition. We were seeing these segfaults in NixOS 24.11, VPP 24.10 and 25.06.
>From our initial analysis notes of it, we observed that the WireGuard plugin in VPP creates L3 tunnel interfaces (i.e., they do not possess an underlying L2 Ethernet header, and thus no MAC address). When we attempted to assign an IP address to a WG interface, the synchronization routine gets triggered, and as vnet_hw_interface_t lacks a valid MAC address vector or an Ethernet hardware class, we get an immediate SIGSEGV, and the crash message: `Secondary MAC Addresses not supported for interface index xx`. While walking up that trail, we found our likely culprit, and then dug further for other possible similar causes. We had initial suspicions that this might be related to DPDK PMD functions, but this small edit seemed like an elegant way to resolve our issue and other potential L3 problems, so we added & tested it, and didn't dig further right away. However, whether our issue could also be dependent on Nix or DPDK's PMD doing something silly is definitely a possibility here. We're doing a lot of programmatic changes to interfaces that might not fall under the realm of the "typical" way interfaces are usually configured. -Nat *Nathael Leblanc* CEO & Co-Founder, Joust Security +1.514.800.8071 | [email protected] www.joustsec.com On Thu, Mar 19, 2026 at 4:32 PM Matthew Smith via lists.fd.io <mgsmith= [email protected]> wrote: > 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 (#26899): https://lists.fd.io/g/vpp-dev/message/26899 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]] -=-=-=-=-=-=-=-=-=-=-=-
