In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.
4.13.0-16.194.13.0-17.204.13.0-25.294.13.0-32.354.15.0-10.114.15.0-101.1024.15.0-106.1074.15.0-108.1094.15.0-109.1104.15.0-111.112+130 more6.11.0-8.86.12.0-12.126.12.0-15.156.12.0-16.166.14.0-10.106.14.0-11.116.14.0-13.136.14.0-15.156.14.0-22.226.14.0-23.23+1 more5.3.0-18.195.3.0-24.265.4.0-100.1135.4.0-104.1185.4.0-105.1195.4.0-107.1215.4.0-109.1235.4.0-110.1245.4.0-113.1275.4.0-117.132+109 more5.13.0-19.195.15.0-100.1105.15.0-101.1115.15.0-102.1125.15.0-105.1155.15.0-106.1165.15.0-107.1175.15.0-112.1225.15.0-113.1235.15.0-116.126+67 more4.2.0-16.194.2.0-17.214.2.0-19.234.3.0-1.104.3.0-2.114.3.0-5.164.3.0-6.174.3.0-7.184.4.0-10.254.4.0-101.124+167 more3.11.0-12.193.12.0-1.33.12.0-2.53.12.0-2.73.12.0-3.83.12.0-3.93.12.0-4.103.12.0-4.123.12.0-5.133.12.0-7.15+170 more6.5.0-9.96.6.0-14.146.8.0-11.116.8.0-20.206.8.0-22.226.8.0-28.286.8.0-31.316.8.0-35.356.8.0-36.366.8.0-38.38+21 more5.19.0-1007.7~22.04.15.19.0-1009.9~22.04.15.19.0-1010.10~22.04.15.19.0-1011.11~22.04.15.19.0-1012.12~22.04.15.19.0-1013.13~22.04.15.19.0-1014.14~22.04.15.19.0-1015.15~22.04.14.4.0-1001.104.4.0-1003.124.4.0-1004.134.4.0-1007.164.4.0-1009.184.4.0-1011.204.4.0-1012.214.4.0-1013.224.4.0-1016.254.4.0-1017.26+123 more6.5.0-1008.86.6.0-1001.16.8.0-1001.16.8.0-1006.66.8.0-1008.86.8.0-1009.96.8.0-1010.106.8.0-1011.126.8.0-1012.136.8.0-1013.14+17 more