mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH] fs: don't leak the parent path when openat() fails after the lookup
Date: Wed, 26 Aug 2026 11:40:32 +0200	[thread overview]
Message-ID: <20260826094033.2545168-1-a.fatoum@pengutronix.de> (raw)

openat() jumps to out1 on three errors that happen after the lookup has
succeeded, and none of them drops what the lookup took:

- create() failing leaves both the negative dentry that filename_create()
  returned and the parent path it filled in.
- The -ENOENT branch dputs the dentry, which is path.dentry here, but not
  the vfsmount reference held alongside it.
- The -EISDIR branch drops nothing at all.

The leaked vfsmount reference keeps the file system busy for good:

  barebox:/ mount -t efivarfs none /efivarfs
  barebox:/ echo -o /efivarfs/Foo-8be4df61-93ca-11d2-aa0d-00e098032b8c x
  open: Operation not permitted
  barebox:/ umount /efivarfs
  umount: Device or resource busy

efivarfs refuses to create variables outside barebox' vendor GUID, so a
single mistyped GUID is enough to reach this; any file system whose
create() can fail - a full FAT, a read-only mount - gets there the same
way. Release the path on all three paths, as mknodat() already does for
the same filename_create() result.

Assisted-by: Claude:opus-5
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 fs/fs.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index dc6c30802d89..ce41f23f880b 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -2748,8 +2748,11 @@ int openat(int dirfd, const char *pathname, int flags)
 	if (d_is_negative(dentry)) {
 		if (flags & O_CREAT) {
 			error = create(path.dentry, dentry);
-			if (error)
+			if (error) {
+				dput(dentry);
+				path_put(&path);
 				goto out1;
+			}
 			/* repoint path.dentry from parent to newly created entry.
 			 * path.mnt already points at the correct vfsmount, even
 			 * for a dirfd of the root directory, so that's fine.
@@ -2757,12 +2760,13 @@ int openat(int dirfd, const char *pathname, int flags)
 			dput(path.dentry);
 			path.dentry = dentry;
 		} else {
-			dput(dentry);
+			path_put(&path);
 			error = -ENOENT;
 			goto out1;
 		}
 	} else if (d_is_dir(dentry)) {
 		if (!(flags & (O_PATH | O_DIRECTORY)) && !dentry_is_tftp(dentry)) {
+			path_put(&path);
 			error = -EISDIR;
 			goto out1;
 		}
-- 
2.47.3




             reply	other threads:[~2026-08-26  9:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  9:40 Ahmad Fatoum [this message]
2026-08-28 13:01 ` Sascha Hauer

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=20260826094033.2545168-1-a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.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