linux-kernel - [PATCH v2] ext[234]: Return -EIO not -ESTALE on directory traversal through deleted inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1234833003-19631-1-git-send-email-bdonlan@gmail.com>
Date:	Mon, 16 Feb 2009 20:10:03 -0500
From:	Bryan Donlan <bdonlan@...il.com>
To:	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	sct@...hat.com, akpm@...ux-foundation.org, adilger@....com,
	tytso@....edu, Bryan Donlan <bdonlan@...il.com>
Subject: [PATCH v2] ext[234]: Return -EIO not -ESTALE on directory traversal through deleted inode

The ext[234]_iget() functions in the ext[234] family of filesystems returns
-ESTALE if invoked on a deleted inode, in order to report errors to NFS
properly. However, in ext[234]_lookup(), this -ESTALE can be propagated to
userspace if the filesystem is corrupted such that a directory entry
references a deleted inode. This leads to a misleading error message - "Stale
NFS file handle" - and confusion on the part of the admin.

The bug can be easily reproduced by creating a new filesystem, making a link
to an unused inode using debugfs, then mounting and attempting to ls -l
said link.

This patch thus changes ext[234]_lookup to return -EIO if it receives -ESTALE
from ext[234]_iget(), as ext[234] does for other filesystem metadata
corruption; and also invokes the appropriate ext*_error functions when
this case is detected.

Signed-off-by: Bryan Donlan <bdonlan@...il.com>
---
 fs/ext2/namei.c |   12 ++++++++++--
 fs/ext3/namei.c |   12 ++++++++++--
 fs/ext4/namei.c |   12 ++++++++++--
 3 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/fs/ext2/namei.c b/fs/ext2/namei.c
index 90ea179..e3d2d34 100644
--- a/fs/ext2/namei.c
+++ b/fs/ext2/namei.c
@@ -66,8 +66,16 @@ static struct dentry *ext2_lookup(struct inode * dir, struct dentry *dentry, str
 	inode = NULL;
 	if (ino) {
 		inode = ext2_iget(dir->i_sb, ino);
-		if (IS_ERR(inode))
-			return ERR_CAST(inode);
+		if (unlikely(IS_ERR(inode))) {
+			if (PTR_ERR(inode) == -ESTALE) {
+				ext2_error(dir->i_sb, "ext2_lookup",
+						"deleted inode referenced: %lu",
+						ino);
+				return ERR_PTR(-EIO);
+			} else {
+				return ERR_CAST(inode);
+			}
+		}
 	}
 	return d_splice_alias(inode, dentry);
 }
diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
index 4db4ffa..7a99af0 100644
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -1047,8 +1047,16 @@ static struct dentry *ext3_lookup(struct inode * dir, struct dentry *dentry, str
 			return ERR_PTR(-EIO);
 		}
 		inode = ext3_iget(dir->i_sb, ino);
-		if (IS_ERR(inode))
-			return ERR_CAST(inode);
+		if (unlikely(IS_ERR(inode))) {
+			if (PTR_ERR(inode) == -ESTALE) {
+				ext3_error(dir->i_sb, "ext2_lookup",
+						"deleted inode referenced: %lu",
+						ino);
+				return ERR_PTR(-EIO);
+			} else {
+				return ERR_CAST(inode);
+			}
+		}
 	}
 	return d_splice_alias(inode, dentry);
 }
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index ba702bd..a61637b 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1052,8 +1052,16 @@ static struct dentry *ext4_lookup(struct inode *dir, struct dentry *dentry, stru
 			return ERR_PTR(-EIO);
 		}
 		inode = ext4_iget(dir->i_sb, ino);
-		if (IS_ERR(inode))
-			return ERR_CAST(inode);
+		if (unlikely(IS_ERR(inode))) {
+			if (PTR_ERR(inode) == -ESTALE) {
+				ext4_error(dir->i_sb, "ext2_lookup",
+						"deleted inode referenced: %u",
+						ino);
+				return ERR_PTR(-EIO);
+			} else {
+				return ERR_CAST(inode);
+			}
+		}
 	}
 	return d_splice_alias(inode, dentry);
 }
-- 
1.5.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/