[PATCH] firewire: cdev: fix 32 bit userland on 64 bit kernel compatcorner cases

From: Stefan Richter
Date: Wed Aug 10 2011 - 18:06:22 EST

Clemens points out that we need to use compat_ptr() in order to safely
cast from u64 to addresses of a 32-bit usermode client.

Before, our conversion went wrong
- in practice if the client cast from pointer to integer such that
sign-extension happened, (libraw1394 and libdc1394 at least were not
doing that, IOW were not affected)
- in theory on s390 (which doesn't have FireWire though) and on the
tile architecture, regardless of what the client does.
The bug would usually be observed as the initial get_info ioctl failing
with "Bad address" (EFAULT).

Reported-by: Carl Karsten <carl@xxxxxxxxxxxxxxxxx>
Reported-by: Clemens Ladisch <clemens@xxxxxxxxxx>
Signed-off-by: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxx
drivers/firewire/core-cdev.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)

Index: b/drivers/firewire/core-cdev.c
--- a/drivers/firewire/core-cdev.c
+++ b/drivers/firewire/core-cdev.c
@@ -216,15 +216,33 @@ struct inbound_phy_packet_event {
struct fw_cdev_event_phy_packet phy_packet;

-static inline void __user *u64_to_uptr(__u64 value)
+static void __user *u64_to_uptr(u64 value)
+ if (is_compat_task())
+ return compat_ptr(value);
+ else
+ return (void __user *)(unsigned long)value;
+static u64 uptr_to_u64(void __user *ptr)
+ if (is_compat_task())
+ return ptr_to_compat(ptr);
+ else
+ return (u64)(unsigned long)ptr;
+static inline void __user *u64_to_uptr(u64 value)
return (void __user *)(unsigned long)value;

-static inline __u64 uptr_to_u64(void __user *ptr)
+static inline u64 uptr_to_u64(void __user *ptr)
- return (__u64)(unsigned long)ptr;
+ return (u64)(unsigned long)ptr;
+#endif /* CONFIG_COMPAT */

static int fw_device_op_open(struct inode *inode, struct file *file)

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