linux-kernel - [PATCH] XFS: don't expose sysv device encoding in inode->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 for Android: free password hash cracker in your pocket

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

Message-Id: <200712190404.lBJ44IOf003182@agora.fsl.cs.sunysb.edu>
Date:	Tue, 18 Dec 2007 23:04:18 -0500
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, xfs-masters@....sgi.com,
	xfs@....sgi.com
Subject: [PATCH] XFS: don't expose sysv device encoding in inode->i_rdev

I did some testing on special-file copyup in unionfs, whereby unionfs calls
vfs_mknod on a lower f/s to create (copyup) a device.  The copyup
functionality worked fine when unionfs was stacked on top of all file
systems other than xfs.  I found out that when I create a device with
<maj,min> on xfs, then I stat(1) through the union, I get the sysv encoding
of the <maj,min>.

The problem appears to be in the xfs_vn_mknod() function in xfs_iops.c: the
code changes the rdev value using rdev = sysv_encode_dev(rdev); so it can
fall through that case of the first switch statement in that function, and
onto xfs_create().  Later in that function, however, it copies the
sysv_encode'd rdev value into the inode that is going to be d_instantiate'd,
thus exposing the sysv encoding to the VFS -- and to any stackable file
system that may be using fsstack_copy_attr_all() to copy lower inode
attributes to an upper inode.

The following small patch seems to fix the problem.  Bug and fix were
verified on v2.6.24-rc5-245-gc63a119.  Someone with better understanding of
XFS's internals should verify this patch.

Andrew, a related question: kdev_t.h defines several device <maj,min>
encoding formats, which different file systems seems to use.  Assuming that
a file system can choose whatever internal encoding it wants, is there a
uniform standard for what the VFS-level inode->i_rdev format should be?
(vfs.txt is silent about the issue.)

Thanks,
Erez.

XFS: don't expose internal sysv encoding to VFS inode->i_rdev

Signed:-off-by: Erez Zadok <ezk@...sunysb.edu>

diff --git a/fs/xfs/linux-2.6/xfs_iops.c b/fs/xfs/linux-2.6/xfs_iops.c
index 37e1167..daaa060 100644
--- a/fs/xfs/linux-2.6/xfs_iops.c
+++ b/fs/xfs/linux-2.6/xfs_iops.c
@@ -333,7 +333,8 @@ xfs_vn_mknod(
 		ip = vn_to_inode(vp);

 		if (S_ISCHR(mode) || S_ISBLK(mode))
-			ip->i_rdev = rdev;
+			ip->i_rdev = MKDEV(sysv_major(rdev) & 0x1ff,
+					   sysv_minor(rdev));
 		else if (S_ISDIR(mode))
 			xfs_validate_fields(ip);
 		d_instantiate(dentry, ip);
--
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/