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 (#26897): https://lists.fd.io/g/vpp-dev/message/26897 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]] -=-=-=-=-=-=-=-=-=-=-=-
