Page MenuHomeFreeBSD

tun/tap: close race between destroy/ioctl handler
ClosedPublic

Authored by kevans on Apr 23 2019, 4:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 8, 11:44 AM
Unknown Object (File)
Sep 16 2025, 5:17 PM
Unknown Object (File)
Sep 10 2025, 11:33 PM
Unknown Object (File)
Sep 1 2025, 5:07 PM
Unknown Object (File)
Aug 20 2025, 12:14 PM
Unknown Object (File)
Aug 14 2025, 4:37 AM
Unknown Object (File)
Aug 3 2025, 9:50 AM
Unknown Object (File)
Jul 22 2025, 3:51 PM
Subscribers

Details

Summary

It seems that there should be a better way to handle this, but this seems to be the more common approach and it should likely get replaced in all of the places it happens... Basically, thread 1 is in the process of destroying the tun/tap while thread 2 is executing one of the ioctls that requires the tun/tap mutex and the mutex is destroyed before the ioctl handler can acquire it.

This is only one of the races described/found in PR 233955.

PR: 233955

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Actually functional, after a little bit more coffee and testing... previous version caused trivial deadlock as follows:

1.) ifconfig tun1 create
2.) ifconfig tun1 10.10.1.1 10.10.1.2
3.) ifconfig tun1 destroy

*_destroy only needs to hold ioctl_sx long enough to invalidate the if_softc, while the ioctl handler needs to hold it to guarantee liveness until it's done. Minimize the destroy bits.

This revision is now accepted and ready to land.Apr 24 2019, 9:59 AM
This revision was automatically updated to reflect the committed changes.