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