Closed ncw closed 2 years ago
Given that cgofuse is just a thin layer over the underlying FUSE library this may actually be a problem with WinFsp-FUSE (i.e. the FUSE layer of WinFsp). I note that I do not know of any file system (and certainly not any of the test file systems) that uses the path
argument of release
so this is why it may have gone unnoticed so far.
Looking at the WinFsp-FUSE code in fuse_intf.c
I can only find two locations where release
is being called:
fsp_fuse_intf_Close
- This happens when the kernel closes a file. I do not see anything suspicious here.fsp_fuse_intf_Create
- This happens when the kernel wants to create a file. If the file creation fails after the file has been opened (e.g. because a chown
failed) the opened file must be closed using release
. It looks like I messed up in this case and pass filedesc->PosixPath
which has not been initialized yet. I believe I should be passing contexthdr->PosixPath
(and indeed that is what the rest of this function uses). Sorry for that.I will add a commit to WinFsp to fix this problem.
I have added the commit referenced above, which should hopefully fix this problem.
Given that cgofuse is just a thin layer over the underlying FUSE library this may actually be a problem with WinFsp-FUSE (i.e. the FUSE layer of WinFsp). I note that I do not know of any file system (and certainly not any of the test file systems) that uses the
path
argument ofrelease
so this is why it may have gone unnoticed so far.
Ah. Rclone does everything with paths and almost complete ignores inodes which is not the usual way of building file systems.
Looking at the WinFsp-FUSE code in
fuse_intf.c
I can only find two locations whererelease
is being called:
fsp_fuse_intf_Close
- This happens when the kernel closes a file. I do not see anything suspicious here.fsp_fuse_intf_Create
- This happens when the kernel wants to create a file. If the file creation fails after the file has been opened (e.g. because achown
failed) the opened file must be closed usingrelease
.
That explains why it doesn't happen very often as it needs an additional error in create to trigger it.
It looks like I messed up in this case and pass
filedesc->PosixPath
which has not been initialized yet. I believe I should be passingcontexthdr->PosixPath
(and indeed that is what the rest of this function uses). Sorry for that.
No apologies necessary!
I have added the commit referenced above, which should hopefully fix this problem.
Excellent - thank you Bill :-)
Would it be possible for you to make a test build of WinFSP with this fix in so I can get the original poster to try it?
(I should do this myself really but I don't feel confident building WinFSP - my Windows VM doesn't have any of the MS dev tools on it and I don't know how to use them!)
Would it be possible for you to make a test build of WinFSP with this fix in so I can get the original poster to try it?
I will see if I can produce a new Beta build during the weekend. I am in the process of moving and may not be able to do so timely.
(I should do this myself really but I don't feel confident building WinFSP - my Windows VM doesn't have any of the MS dev tools on it and I don't know how to use them!)
Building WinFsp is quite easy, but the problem is that the final build product needs to be signed. Windows will not run unsigned drivers unless you boot in "testsigning" mode. So even if you could build it, it might not be very useful.
Thanks Bill and no hurry :-) I hope the move goes well.
I have added a new WinFsp release which should hopefully fix the issue:
https://github.com/billziss-gh/winfsp/releases/tag/v1.10B2
Please download this latest release and let me know if it fixes the problem.
I've given the people who had this problem the above link and I'll report back here on their testing.
@ncw do you know if the latest WinFsp release has fixed the problem?
As far as I know it has fixed the problem - no more reports of it in the forum or the rclone bug tracker so I'll close this now.
Thank you :-)
We've had several reports in the rclone forum of a crash which appears to be something to do with cgofuse. I dismissed these as some random stuff up with Windows, but we've had 3 reports now which is more than the co-incidence level!
These produced 3 very similar tracebacks
The middle one of those reports has a mad pointer of 0x2f736569766f4d2f which decodes in ASCII as
/seivoM/
which is highly suggestive of a use after free.The other two have the pointer 0x500000000000501 which could be valid but looks a little fishy too.
If you check the forum posts I linked above then you'll see a bit more analysis.
So I think this is probably a use after free due to handling of Go strings, but I'm not certain!
Any help much appreciated.