CVE-2026-23103

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Make the addrs_lock be per port<br /> <br /> Make the addrs_lock be per port, not per ipvlan dev.<br /> <br /> Initial code seems to be written in the assumption,<br /> that any address change must occur under RTNL.<br /> But it is not so for the case of IPv6. So<br /> <br /> 1) Introduce per-port addrs_lock.<br /> <br /> 2) It was needed to fix places where it was forgotten<br /> to take lock (ipvlan_open/ipvlan_close)<br /> <br /> This appears to be a very minor problem though.<br /> Since it&amp;#39;s highly unlikely that ipvlan_add_addr() will<br /> be called on 2 CPU simultaneously. But nevertheless,<br /> this could cause:<br /> <br /> 1) False-negative of ipvlan_addr_busy(): one interface<br /> iterated through all port-&gt;ipvlans + ipvlan-&gt;addrs<br /> under some ipvlan spinlock, and another added IP<br /> under its own lock. Though this is only possible<br /> for IPv6, since looks like only ipvlan_addr6_event() can be<br /> called without rtnl_lock.<br /> <br /> 2) Race since ipvlan_ht_addr_add(port) is called under<br /> different ipvlan-&gt;addrs_lock locks<br /> <br /> This should not affect performance, since add/remove IP<br /> is a rare situation and spinlock is not taken on fast<br /> paths.