[Bug 235704] [net] [patch] tun(4) can't be destroyed on a VNET jail if it's renamed

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235704

            Bug ID: 235704
           Summary: [net] [patch] tun(4) can't be destroyed on a VNET jail
                    if it's renamed
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: genneko217 at gmail.com

Created attachment 201965
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201965&action=edit
diff to /usr/src

If a tun(4) interface is created on a VNET jail and renamed to the name
other than "tunX", the interface cannot be destroyed thereafter. If it
is renamed back to "tunX", it becomes destroyable again. This issue only
occurs on VNET jails and doesn't seem to happen on a host or a/non-VNET
environment.


How to Reproduce:

1. Boot a VIMAGE-enabled FreeBSD system.
   (I used 12.0-RELEASE-p3 with GENERIC kernel. See attached log.txt)
2. Create a VNET jail.
3. Create a tun(4) interface on the VNET jail,
   then rename it to the name other than "tunX".
4. Try to destroy the tun interface on the VNET jail.

Expected Result: Step 4 removes the interface successfully.
Actual Result: Step 4 fails with "SIOCIFDESTROY: Invalid argument".


Minimal Set of Commands to Reproduce:
(Assume the second command creates 'tun0')

jail -c -n test vnet persist
jexec test ifconfig tun create
jexec test ifconfig tun0 name wg0
jexec test ifconfig wg0 destroy


Workaround:

The problem can be worked around by renaming the undestroyable tun
interface to "tunX" (X can be any number which is not being used by
other tun interfaces on the system).

jexec test ifconfig wg0 name tun0
jexec test ifconfig tun0 destroy


Possible Fix:

See attached patch for if_clone_destroy() in sys/net/if_clone.c.

I wrote and tested it on releng/12.0 and confirmed it solved this
particular problem, but because of my lack of knowledge and experience
(this is my first kernel debugging, report and patch submission ever)
I'm not sure it's reasonable and doesn't break any other stuff.


Background:

I found this issue when I was experimenting with the WireGuard VPN
(net/wireguard package) on VNET jails.

On FreeBSD, WireGuard uses a userspace program (net/wireguard-go) to
create its tunnel interface. The program first generates a tun interface
by opening /dev/tun, then renames it to the one specified on the command
line.

When I used 'wg0' as the WireGuard interface name on a VNET jail, I
noticed that it couldn't be destroyed as 'service wireguard stop' got
stuck waiting the interface to be destroyed.

Further investigation shows me that it's not specific to WireGuard.
Thus I create this report.

-- 
You are receiving this mail because:
You are the assignee for the bug.