linux-kernel - Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86

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]

Date:	Tue, 05 Dec 2006 14:19:53 +0000
From:	David Howells <dhowells@...hat.com>
To:	Chuck Ebbert <76306.1226@...puserve.com>
Cc:	Andrew Morton <akpm@...l.org>, Kasper Sandberg <lkml@...anurb.dk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>, ak@....de, vojtech@...e.cz
Subject: Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64 

Chuck Ebbert <76306.1226@...puserve.com> wrote:

> Here is a patch to reverse that.  Kasper, can you test it?
> (Your filesystem is on a FAT/VFAT volume, I assume.)

Please don't revert that patch.  If you do, you'll break CONFIG_BLOCK=n.

Can you compile and run the attached program as both 32-bit and 64-bit?

On my x86_64 test box, I did:

	[root@...romeda ~]# mkfs.vfat /dev/sda5
	[root@...romeda ~]# mount /dev/sda5 /mnt
	[root@...romeda ~]# mkdir /mnt/a
	[root@...romeda ~]# /tmp/ioctl /mnt/a		# 32-bit
	268 : 82187201, 82187202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	Calling VFAT_IOCTL_READDIR_BOTH
	[root@...romeda ~]# /tmp/ioctl /mnt/a		# 64-bit
	280 : 82307201, 82307202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	ioctl: Inappropriate ioctl for device
	Calling VFAT_IOCTL_READDIR_BOTH

Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function).  Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:

	[root@...romeda ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
	280 : 82307201, 82307202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	ioctl(0x3, 0x82187201, 0x7fff9cec36c0)  = -1 (errno 25)
	ioctl: Inappropriate ioctl for device
	Calling VFAT_IOCTL_READDIR_BOTH
	ioctl(0x3, 0x82307201, 0x7fff9cec3490)  = 0x1
	Process 3410 detached

Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:

	==> fat_compat_dir_ioctl(82187201,ffa803b8)
	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
	<== fat_dir_ioctl() = 1
	<== fat_compat_dir_ioctl() = 1
	==> fat_compat_dir_ioctl(82187201,ffa801a0)
	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
	<== fat_dir_ioctl() = 1
	<== fat_compat_dir_ioctl() = 1

and this for the 64-bit compilation:

	==> fat_dir_ioctl(82187201,7fff031f69f0)
	call fat_generic_ioctl()
	<== fat_dir_ioctl() = -25
	==> fat_dir_ioctl(82307201,7fff031f67c0)
	<== fat_dir_ioctl() = 1

Which is entirely what I'd expect.

However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls.  If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?

| i have only tested with >=rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system

How do you get that?  I don't see anything like that.  I've tried:

	echo 1 >/proc/sys/kernel/compat-log

But that doesn't seem to do anything.

David


View attachment "ioctl.c" of type "text/x-c" (3054 bytes)

View attachment "ioctl.diff" of type "text/x-patch" (1366 bytes)