The VFAT compat ioctls in the Linux kernel before 2.6.21.2, when run on a 64-bit system, allow local users to corrupt a kernel_dirent struct and cause a denial of service (system crash) via unknown vectors. http://www.securityfocus.com/bid/24134
Looks like testcase & upstream commit is at: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c483bab099cb89e92b7cad94a52fcdaf37e56657
Created attachment 158990 [details] Upstream supporting patch, backported for RHEL5 Not strictly necessary, but this upstream patch (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=188f83dfe0eeecd1427d0d255cc97dbf7ef6b4b7 ) eases the backport of the fix. It's a simple code move of fat compat ioctls into fs/fat/dir.c from fs/compat_ioctl.c
Created attachment 158991 [details] Upstream resolution patch, backported for RHEL5 The actual fix, applies on top of the last attachment.
Note also that this changes KABI on fat_* symbols but I don't think they're in the whitelist - Early on, I asked them to be removed, in any case... --- /build/obj/kabi-test/Module.symvers.orig 2007-06-14 13:56:51.970823381 -0500 +++ /build/obj/kabi-test/Module.symvers 2007-07-11 13:23:33.168300526 -0500 -0x530aec08 fat_dir_empty fs/fat/fat EXPORT_SYMBOL_GPL +0xc5967420 fat_dir_empty fs/fat/fat EXPORT_SYMBOL_GPL -0xfcca0992 fat_add_entries fs/fat/fat EXPORT_SYMBOL_GPL +0x705e2f60 fat_add_entries fs/fat/fat EXPORT_SYMBOL_GPL -0x41181e25 fat_get_dotdot_entry fs/fat/fat EXPORT_SYMBOL_GPL +0xba4b0f17 fat_get_dotdot_entry fs/fat/fat EXPORT_SYMBOL_GPL -0x4ce5aa5a fat_search_long fs/fat/fat EXPORT_SYMBOL_GPL +0x9f0ba2c5 fat_search_long fs/fat/fat EXPORT_SYMBOL_GPL -0x0bca81db fat_alloc_new_dir fs/fat/fat EXPORT_SYMBOL_GPL +0xa524a16d fat_alloc_new_dir fs/fat/fat EXPORT_SYMBOL_GPL -0xb54f6db5 fat_scan fs/fat/fat EXPORT_SYMBOL_GPL +0xf2d7dd2e fat_scan fs/fat/fat EXPORT_SYMBOL_GPL -0x8180a222 fat_remove_entries fs/fat/fat EXPORT_SYMBOL_GPL +0x117f8975 fat_remove_entries fs/fat/fat EXPORT_SYMBOL_GPL
So far I actually cannot reproduce this on rhel-4.6, need to look into why that is.
Ugh, scratch that, forgot to build test as 32 bit binary on rhel4. Yes, it's vulnerable.