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