mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
To: Tyler Hicks <code@tyhicks.com>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nickolai Zeldovich <nickolai@csail.mit.edu>
Subject: [PATCH v1] ecryptfs: release the inode when lookup fails to read the file size
Date: Sat, 17 Oct 2026 22:38:39 -0400	[thread overview]
Message-ID: <20261018023840.798718-1-nickolai@csail.mit.edu> (raw)

When eCryptfs cannot open the lower file of a regular file during
lookup, the lookup fails and leaks the eCryptfs inode it got, together
with that inode's reference on the lower inode.  Every failed lookup
leaks one more inode, and unmounting reports "VFS: Busy inodes after
unmount of ecryptfs" (a BUG with CONFIG_BUG_ON_DATA_CORRUPTION).  The
lower open fails, for example, with -ETXTBSY while the lower file is
being executed, or when an LSM or the lower file system's ->open()
refuses it; any user who can look up the name can repeat it.  A
concurrent lookup that found the new inode before it was unhashed
waits for I_NEW forever.

ecryptfs_lookup_interpose() gets the inode from iget5_locked() and,
for a regular file, reads the plaintext size with
ecryptfs_i_size_read() before unlocking a new inode.  On failure it
marks the inode bad and returns, but it neither clears I_NEW nor drops
the reference it holds.  The error path came with the deferred
unlock_new_inode() in commit 3b06b3ebf441 ("eCryptfs: Fix new inode
race condition").

Unlock a new inode and drop the reference on that path, as
iget_failed() does for a new inode.

Tested on x86_64 with a lower file on tmpfs that a process is
executing: 1000 failed stat() calls left 1000 inodes allocated and the
unmount warned about busy inodes; with the patch no inode is left and
the unmount is clean.

Fixes: 3b06b3ebf441 ("eCryptfs: Fix new inode race condition")
Assisted-by: LLM
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
---

Notes:
    Reproducer (CONFIG_ECRYPT_FS, CONFIG_TMPFS, CONFIG_KEYS; runs as /init
    in QEMU, root; the key is a dummy auth_tok, nothing gets encrypted):
    
      gcc -O2 -static -o init ecryptfs_inew.c   # packed as /init in an initramfs
      qemu-system-x86_64 -m 1G -nographic -kernel bzImage -initrd initramfs.cpio \
          -append "console=ttyS0 rdinit=/init"
    
    Before:
      stat: Text file busy
      inodes left by 1000 failed lookups: 1000
      VFS: Busy inodes after unmount of ecryptfs (ecryptfs)   (console)
      unmounted
    After:
      stat: Text file busy
      inodes left by 1000 failed lookups: 0
      unmounted
    
    The same leak was reported on the list as "[BUG] ecryptfs leaks an inode
    on lookup failure -> kernel BUG in generic_shutdown_super()" (Farhad
    Alemi, 2026-08-27), with -ETXTBSY from the lower open.
    
    /*
     * Look up a lower file that is being executed through eCryptfs 1000 times,
     * count the inodes left behind, then unmount.
     * Runs as /init in QEMU; needs CONFIG_ECRYPT_FS, CONFIG_TMPFS, CONFIG_KEYS.
     */
    #include <fcntl.h>
    #include <linux/keyctl.h>
    #include <stdio.h>
    #include <sys/mount.h>
    #include <sys/reboot.h>
    #include <sys/stat.h>
    #include <sys/sendfile.h>
    #include <sys/syscall.h>
    #include <unistd.h>
    
    static long inodes(void)
    {
    	long n = -1;
    	FILE *f = fopen("/proc/sys/fs/inode-nr", "r");
    
    	if (f) {
    		if (fscanf(f, "%ld", &n) != 1)
    			n = -1;
    		fclose(f);
    	}
    	return n;
    }
    
    int main(int argc, char **argv)
    {
    	static char tok[1024];
    	int fd, in, i;
    	long n;
    	struct stat st;
    
    	if (argc > 1) {		/* the copy in the lower directory */
    		pause();
    		return 0;
    	}
    
    	mount("proc", "/proc", "proc", 0, NULL);
    	mkdir("/lower", 0755);
    	mkdir("/upper", 0755);
    	mount("tmpfs", "/lower", "tmpfs", 0, NULL);
    	in = open("/init", O_RDONLY);
    	fstat(in, &st);
    	fd = open("/lower/f", O_CREAT | O_WRONLY, 0755);
    	sendfile(fd, in, NULL, st.st_size);
    	close(fd);
    	close(in);
    	if (!fork()) {
    		execl("/lower/f", "f", "sleep", NULL);
    		_exit(1);
    	}
    	sleep(1);
    
    	tok[0] = 0x04;		/* auth_tok version 0.4, ECRYPTFS_PASSWORD */
    	if (syscall(SYS_add_key, "user", "0123456789abcdef", tok, sizeof(tok),
    		    KEY_SPEC_USER_KEYRING) < 0)
    		perror("add_key");
    	if (mount("/lower", "/upper", "ecryptfs", 0,
    		  "ecryptfs_sig=0123456789abcdef,ecryptfs_cipher=aes,ecryptfs_key_bytes=16"))
    		perror("mount ecryptfs");
    
    	n = inodes();
    	for (i = 0; i < 1000; i++)
    		if (stat("/upper/f", &st) && i == 0)
    			printf("stat: %m\n");
    	printf("inodes left by 1000 failed lookups: %ld\n", inodes() - n);
    	if (umount("/upper"))
    		perror("umount");
    	printf("unmounted\n");
    	fflush(stdout);
    	reboot(RB_POWER_OFF);
    	return 0;
    }

 fs/ecryptfs/inode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 525297c7ebd8..d7e90192efcf 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -363,6 +363,9 @@ static struct dentry *ecryptfs_lookup_interpose(struct dentry *dentry,
 		rc = ecryptfs_i_size_read(dentry, inode);
 		if (rc) {
 			make_bad_inode(inode);
+			if (inode_state_read_once(inode) & I_NEW)
+				unlock_new_inode(inode);
+			iput(inode);
 			return ERR_PTR(rc);
 		}
 	}

base-commit: 58161ead29e50d70a317ea26b472e0c7508e69da
-- 
2.53.0


             reply	other threads:[~2026-10-18  2:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-18  2:38 Nickolai Zeldovich [this message]
2026-10-19 22:28 ` Tyler Hicks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261018023840.798718-1-nickolai@csail.mit.edu \
    --to=nickolai@csail.mit.edu \
    --cc=code@tyhicks.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®