NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/57872: A possible double fetch in sys/fs/ntfs/ntfs_subr.c



>Number:         57872
>Category:       kern
>Synopsis:       A possible double fetch in sys/fs/ntfs/ntfs_subr.c
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 23 16:55:00 +0000 2024
>Originator:     Tuo Li
>Release:        9.3
>Organization:
Tsinghua University
>Environment:
NetBSD localhost 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
In the function ntfs_ntput(), ip->i_usecount is checked to be less than zero. If it is less than zero, a panic will be triggered: 

462  if (ip->i_usecount < 0) { 
463    panic("ntfs_ntput: ino: %llu usecount: %d ",
464       (unsigned long long)ip->i_number, ip->i_usecount);
465  }

If ip->i_usecount is equal to or greater than zero, the lock ip->i_interlock is released, which is followed by an access to ip->i_usecount:

472  if (ip->i_usecount == 0) {}

However, ip->i_usecount can be updated with a new value by another thread, and thus the check at Line 462 can be bypassed.

I am not quite sure whether this possible double fetch is real and how to fix them if they are real. 

Any feedback would be appreciated, thanks!

>How-To-Repeat:
This possible double fetch is found by an experimental static analysis tool developed by myself. Therefore, I can not repeat the problem.
>Fix:



Home | Main Index | Thread Index | Old Index