linux-kernel - Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i

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: <1216401356.11215.15.camel@norville.austin.ibm.com>
Date:	Fri, 18 Jul 2008 12:15:56 -0500
From:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	jfs-discussion@...ts.sourceforge.net,
	Johannes Weiner <hannes@...urebad.de>,
	linux-kernel@...r.kernel.org
Subject: Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)

On Fri, 2008-07-18 at 10:10 +0200, Vegard Nossum wrote:

> But whether it truly helped or not, I don't know. I got something different now:
> 
> jfs_unlink: dtDelete returned -116
> jfs_unlink: dtDelete returned -116
> ------------[ cut here ]------------
> kernel BUG at fs/inode.c:262!

        BUG_ON(inode->i_data.nrpages);

> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Pid: 387, comm: jfsCommit Not tainted (2.6.26-03415-gdf3030b #45)
> EIP: 0060:[<c01b96f9>] EFLAGS: 00010206 CPU: 0
> EIP is at clear_inode+0x149/0x160
> EAX: 00000005 EBX: f56e283c ECX: f7242fd0 EDX: 00000000
> ESI: f56e2568 EDI: 00000000 EBP: f79f9f0c ESP: f79f9f04
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process jfsCommit (pid: 387, ti=f79f8000 task=f7242fd0 task.ti=f79f8000)
> Stack: 00000001 f56e283c f79f9f24 c02de258 c08f7ba0 f79f9f24 c02de220 f56e283c
>        f79f9f34 c01b9ba1 f56e283c 00000000 f79f9f44 c01b9d67 f56e283c 00000000
>        f79f9f50 c01b8be7 f56e283c f79f9f9c c02fd5b5 f88261bc f79f9f70 c0159173

> 
> ...but it might just be a different error altogether.

I think it is.  Your test corrupt more than just di_nlink, right?  There
is a test in jfs_delete_inode() for JFS_IP(inode)->fileset ==
FILESYSTEM_I.  If the test fails, we don't call truncate_inode_pages().
Nowhere do we validate that fileset = FILESYSTEM_I when we read the
inode from disk.

I'm pondering whether it would be okay to remove the silly test in
jfs_delete_inode(), or whether I need to validate the field when we read
in the inode.

Hmm.  The fileset is written to the journal, so it really should be
validated.

Here's another patch

JFS: validate di_fileset when reading inode from disk.

Signed-off-by: Dave Kleikamp <shaggy@...ux.vnet.ibm.com>

diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
index d6363d8..19df0dd 100644
--- a/fs/jfs/jfs_imap.c
+++ b/fs/jfs/jfs_imap.c
@@ -391,7 +391,10 @@ int diRead(struct inode *ip)
 	dp += rel_inode;
 
 	if (ip->i_ino != le32_to_cpu(dp->di_number)) {
-		jfs_error(ip->i_sb, "diRead: i_ino != di_number");
+		jfs_error(ip->i_sb, "JFS diRead: i_ino != di_number");
+		rc = -EIO;
+	} else if (dp->di_fileset != cpu_to_le32(FILESYSTEM_I)) {
+		jfs_error(ip->i_sb, "JFS diRead: inode is corrupt");
 		rc = -EIO;
 	} else if (le32_to_cpu(dp->di_nlink) == 0)
 		rc = -ESTALE;

-- 
David Kleikamp
IBM Linux Technology Center

--
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/