Hello!
On 1/12/25 9:59 PM, Li Lingfeng wrote:
In nfsd_file_put, after inserting the nfsd_file into the nfsd_file_lru
list, gc may be triggered in another thread and immediately release this
nfsd_file, which will lead to a UAF when accessing this nfsd_file again.
Do you happen to have a reproducer that can trigger this issue?
All the places where unhash is done will also perform lru_remove, so there
is no need to do lru_remove separately here. After inserting the nfsd_file
into the nfsd_file_lru list, it can be released by relying on gc.
Fixes: 4a0e73e635e3 ("NFSD: Leave open files out of the filecache LRU")
The code that is being replaced below was introduced in ac3a2585f018
("nfsd: rework refcounting in filecache"). This fix won't apply to
kernels that have only 4a0e73e635e3 but not ac3a2585f018, for instance.
At the very least we need to add "Cc: stable@xxxxxxxxxxxxxxx # v6.2" but
I'm not convinced "Fixes: 4a0e73e635e3" is correct.
Signed-off-by: Li Lingfeng <lilingfeng3@xxxxxxxxxx>
---
fs/nfsd/filecache.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
index a1cdba42c4fa..37b65cb1579a 100644
--- a/fs/nfsd/filecache.c
+++ b/fs/nfsd/filecache.c
@@ -372,18 +372,10 @@ nfsd_file_put(struct nfsd_file *nf)
/* Try to add it to the LRU. If that fails, decrement. */
if (nfsd_file_lru_add(nf)) {
/* If it's still hashed, we're done */
- if (test_bit(NFSD_FILE_HASHED, &nf->nf_flags)) {
+ if (list_lru_count(&nfsd_file_lru))
nfsd_file_schedule_laundrette();
- return;
- }
The above change does not seem to be related to the fix described
in the patch description. Can you help me understand why this is
needed?
- /*
- * We're racing with unhashing, so try to remove it from
- * the LRU. If removal fails, then someone else already
- * has our reference.
- */
- if (!nfsd_file_lru_remove(nf))
- return;
+ return;
}
}
if (refcount_dec_and_test(&nf->nf_ref))
--
Chuck Lever
