I find this problem and I fix it by a tmp methods. ---------- alexan
--------------原始邮件-------------- 发件人："Nathael Leblanc via lists.fd.io "<[email protected]>; 发送时间：2026年3月19日(星期四) 中午11:52 收件人："[email protected]" <[email protected]>;"neale" <[email protected]>; 主题：[vpp-dev] Patch Review Request - linux-cp: prevent MAC address sync on non-Ethernet interface ----------------------------------- 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: 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. 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 (#26892): https://lists.fd.io/g/vpp-dev/message/26892 Mute This Topic: https://lists.fd.io/mt/118395699/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
