Bug 242841 - tun(4): Unkillable process when attempting to destroy an open tun device
Summary: tun(4): Unkillable process when attempting to destroy an open tun device
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: Kyle Evans
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2019-12-23 20:08 UTC by Colin Percival
Modified: 2020-01-25 03:37 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable12?
koobs: mfc-stable11?

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Percival freebsd_committer freebsd_triage 2019-12-23 20:08:45 UTC 
This is admittedly partly a case of "don't do that" (I tripped over it due to a bug in code I was writing), but it seems like the kernel should handle it a bit more gracefully.

If you:

1. Create a tun device (via SIOCIFCREATE),
2. Open the tun device (via open("/dev/tun#")), and then
3. Attempt to destroy the tun device (via SIOCIFDESTROY),

the SIOCIFDESTROY ioctl will block on tun_condvar until the last file descriptor holding the device open has been closed.  Generally sensible... except that the file descriptor in question is owned by the process which called the ioctl, and it's stuck inside the kernel now and will never be able to close the device.  This results in a process which cannot be killed.

A better solution might be to detect when the process calling SIOCIFDESTROY is the same as the process which owns the tunnel device, and return an error (maybe EBUSY) rather than blocking indefinitely.
Comment 1 Kyle Evans freebsd_committer freebsd_triage 2019-12-24 20:11:01 UTC 
Taking as one of the last to touch tuntap.

I don't see any reason not to do this. We do in general have a problem with applications not actually keeping the owner pid up to date, but it would at least catch the common case.