Applying with these fixes on my side:
- "container root deletes the tunnel or issues a tunnel ioctl on it" ->
  "container root deletes the tunnel, when any process in the
  container issues a tunnel ioctl on it (SIOCGETTUNNEL needs no
  capability)"
- dropped "SIOCADDTUNNEL on such a device also walks the NULL hash in
  vti6_locate()."
- added after "ip link del" keeps working: "A tunnel moved between two
  host netns now has its ioctls served in the creation netns too, so
  SIOCADDTUNNEL on it creates the new tunnel there, as for ip6tnl and
  sit."
- the Jira URL moved next to the Fixes tag, a blank line before
  Feature

On Tue, 10 Nov 2026 17:31:30 +0100, Denis V. Lunev wrote:
> ip6n->fb_tnl_dev, so the node panics on a NULL pointer dereference when
> container root deletes the tunnel or issues a tunnel ioctl on it, when

dev_ioctl() passes SIOCDEVPRIVATE commands to the driver without a
capability check, and SIOCGETTUNNEL has none in vti6_siocdevprivate()
either. Any process in the CT could panic the node, not only root.

> unloaded. SIOCADDTUNNEL on such a device also walks the NULL hash in
> vti6_locate().

Not after 4/6: the ADD path now reads ip6n->fb_tnl_dev first and faults
there, before vti6_locate().

> change. For a moved one the CAP_NET_ADMIN checks of the ioctls now run
> against the creation netns and container root gets EPERM, as it does
> for ip6tnl and sit; "ip link del" keeps working.

With net = self->net for all commands, a vti6 moved between two host
netns changes too: SIOCADDTUNNEL issued on it creates the new tunnel in
the creation netns, and ADD and DEL check CAP_NET_ADMIN there. Mainline
vti6 still uses dev_net(dev) for these. ip6tnl and sit already behave
this way, so this is fine, but the message should say it.

Also note: this EPERM holds for the ioctls only, changelink is still
open to container root. See the reply to the cover letter.

-- 
Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to