[Bug 259071] Read past EoF in NFS client and fusefs
Date: Sat, 30 Oct 2021 23:40:15 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071 --- Comment #9 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2be417843a04f25e631e99d5188eb2652b13d80d commit 2be417843a04f25e631e99d5188eb2652b13d80d Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2021-10-30 23:35:02 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2021-10-30 23:35:02 +0000 PR#259071 provides a test program that fails for the NFS client. Testing with it, there appears to be a race between Lookup and VOPs like Setattr-of-size, where Lookup ends up loading stale attributes (including what might be the wrong file size) into the NFS vnode's attribute cache. The race occurs when the modifying VOP (which holds a lock on the vnode), blocks the acquisition of the vnode in Lookup, after the RPC (with now potentially stale attributes). Here's what seems to happen: Child Parent does stat(), which does VOP_LOOKUP(), doing the Lookup RPC with the directory vnode locked, acquiring file attributes valid at this point in time blocks waiting for locked file does ftruncate(), which vnode does VOP_SETATTR() of Size, changing the file's size while holding an exclusive lock on the file's vnode releases the vnode lock acquires file vnode and fills in now stale attributes including the old wrong Size does a read() which returns wrong data size This patch fixes the problem by saving a timestamp in the NFS vnode in the VOPs that modify the file (Setattr-of-size, Allocate). Then lookup/readdirplus compares that timestamp with the time just before starting the RPC after it has acquired the file's vnode. If the modifying RPC occurred during the Lookup, the attributes in the RPC reply are discarded, since they might be stale. With this patch the test program works as expected. Note that the test program does not fail on a July stable/12, although this race is in the NFS client code. I suspect a fairly recent change to the name caching code exposed this bug. PR: 259071 Reviewed by: asomers MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D32635 sys/fs/nfsclient/nfs_clrpcops.c | 29 +++++++++++++-- sys/fs/nfsclient/nfs_clvnops.c | 78 +++++++++++++++++++++++++++++++++++++---- sys/fs/nfsclient/nfsnode.h | 1 + 3 files changed, 99 insertions(+), 9 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.