Patch "fsnotify: invalidate dcache before IN_DELETE event" has been added to the 5.15-stable tree

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

 



This is a note to let you know that I've just added the patch titled

    fsnotify: invalidate dcache before IN_DELETE event

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     fsnotify-invalidate-dcache-before-in_delete-event.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 4905cf6a309515e9d5836fbf6a37a5c479d0082f
Author: Amir Goldstein <amir73il@xxxxxxxxx>
Date:   Thu Jan 20 23:53:04 2022 +0200

    fsnotify: invalidate dcache before IN_DELETE event
    
    [ Upstream commit a37d9a17f099072fe4d3a9048b0321978707a918 ]
    
    Apparently, there are some applications that use IN_DELETE event as an
    invalidation mechanism and expect that if they try to open a file with
    the name reported with the delete event, that it should not contain the
    content of the deleted file.
    
    Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
    d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
    will have access to a positive dentry.
    
    This allowed a race where opening the deleted file via cached dentry
    is now possible after receiving the IN_DELETE event.
    
    To fix the regression, create a new hook fsnotify_delete() that takes
    the unlinked inode as an argument and use a helper d_delete_notify() to
    pin the inode, so we can pass it to fsnotify_delete() after d_delete().
    
    Backporting hint: this regression is from v5.3. Although patch will
    apply with only trivial conflicts to v5.4 and v5.10, it won't build,
    because fsnotify_delete() implementation is different in each of those
    versions (see fsnotify_link()).
    
    A follow up patch will fix the fsnotify_unlink/rmdir() calls in pseudo
    filesystem that do not need to call d_delete().
    
    Link: https://lore.kernel.org/r/20220120215305.282577-1-amir73il@xxxxxxxxx
    Reported-by: Ivan Delalande <colona@xxxxxxxxxx>
    Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/
    Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
    Cc: stable@xxxxxxxxxxxxxxx # v5.3+
    Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
    Signed-off-by: Jan Kara <jack@xxxxxxx>
    [ cel: adjusted to apply on v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>

diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index c80f448b9b0f2..bb8467cd11ae2 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -240,7 +240,8 @@ static inline void fsnotify_delete(struct inode *dir, struct inode *inode,
 	if (S_ISDIR(inode->i_mode))
 		mask |= FS_ISDIR;
 
-	fsnotify_name(dir, mask, inode, &dentry->d_name, 0);
+	fsnotify_name(mask, inode, FSNOTIFY_EVENT_INODE, dir, &dentry->d_name,
+		      0);
 }
 
 /**




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux