In the Linux kernel, the following vulnerability has been resolved:
vxlan: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net.
vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, …)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here.
Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the require CAP_NET_ADMIN in the device netns for changelink series.
Found by 0sec automated security-research tooling (https://0sec.ai).
References
- https://git.kernel.org/stable/c/32d10c46bfde3e9b274e9e1bd6399d0ebea8f60f
- https://git.kernel.org/stable/c/3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e
- https://git.kernel.org/stable/c/730c7e5fea7f06e0cdf21c547222ec93234fd1d6
- https://git.kernel.org/stable/c/b3793d7dccb192ffff29894d11824db6251acdd5
- https://git.kernel.org/stable/c/e8ad0d311e225939a9a6c745d6cc384c7364ec87