linux/drivers/firewire, branch v3.0.87

firewire: add minor number range check to fw_device_init()

2013-03-03T22:09:04Z

commit 3bec60d511179853138836ae6e1b61fe34d9235f upstream. fw_device_init() didn't check whether the allocated minor number isn't too large. Fail if it goes overflows MINORBITS. Signed-off-by: Tejun Heo Suggested-by: Stefan Richter Acked-by: Stefan Richter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

firewire: net: Fix handling of fragmented multicast/broadcast packets.

2013-01-17T16:43:53Z

commit 9d2373420900a39f5212a3b289331aa3535b1000 upstream. This patch fixes both the transmit and receive portion of sending fragmented mutlicast and broadcast packets. The transmit section was broken because the offset for INTFRAG and LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which was reserved with skb_push() in fwnet_send_packet). The receive section was broken because in fwnet_incoming_packet is a call to fwnet_peer_find_by_node_id(). Called with generation == -1 it will not find a peer and the partial datagrams are associated to a peer. [Stefan R: The fix to use context->card->generation is not perfect. It relies on the IR tasklet which processes packets from the prior bus generation to run before the self-ID-complete worklet which sets the current card generation. Alas, there is no simple way of a race-free implementation. Let's do it this way for now.] Signed-off-by: Stephan Gatzka Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: cdev: fix user memory corruption (i386 userland on amd64 kernel)

2012-10-21T16:17:10Z

commit 790198f74c9d1b46b6a89504361b1a844670d050 upstream. Fix two bugs of the /dev/fw* character device concerning the FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset. (Practically all /dev/fw* clients issue this ioctl right after opening the device.) Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36 without natural alignment and 40 with natural alignment. 1) Memory corruption, affecting i386 userland on amd64 kernel: Userland reserves a 36 bytes large buffer, kernel writes 40 bytes. This has been first found and reported against libraw1394 if compiled with gcc 4.7 which happens to order libraw1394's stack such that the bug became visible as data corruption. 2) Information leak, affecting all kernel architectures except i386: 4 bytes of random kernel stack data were leaked to userspace. Hence limit the respective copy_to_user() to the 32-bit aligned size of struct fw_cdev_event_bus_reset. Reported-by: Simon Kirby Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix too-early completion of IR multichannel buffers

2012-04-02T16:27:13Z

commit 0c0efbacab8d70700d13301e0ae7975783c0cb0a upstream. handle_ir_buffer_fill() assumed that a completed descriptor would be indicated by a non-zero transfer_status (as in most other descriptors). However, this field is written by the controller as soon as (the end of) the first packet has been written into the buffer. As a consequence, if we happen to run into such a descriptor when the interrupt handler is executed after such a packet has completed, the descriptor would be taken out of the list of active descriptors as soon as the buffer had been partially filled, so the event for the buffer being completely filled would never be sent. To fix this, handle descriptors only when they have been completely filled, i.e., when res_count == 0. (This also matches the condition that is reported by the controller with an interrupt.) Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: core: handle ack_busy when fetching the Config ROM

2012-03-19T15:57:43Z

commit aaff12039ffd812d0c8bbff50b87b6f1f09bec3e upstream. Some older Panasonic made camcorders (Panasonic AG-EZ30 and NV-DX110, Grundig Scenos DLC 2000) reject requests with ack_busy_X if a request is sent immediately after they sent a response to a prior transaction. This causes firewire-core to fail probing of the camcorder with "giving up on config rom for node id ...". Consequently, programs like kino or dvgrab are unaware of the presence of a camcorder. Such transaction failures happen also with the ieee1394 driver stack (of the 2.4...2.6 kernel series until 2.6.36 inclusive) but with a lower likelihood, such that kino or dvgrab are generally able to use these camcorders via the older driver stack. The cause for firewire-ohci's or firewire-core's worse behavior is not yet known. Gap count optimization in firewire-core is not the cause. Perhaps the slightly higher latency of transaction completion in the older stack plays a role. (ieee1394: AR-resp DMA context tasklet -> packet completion ktread -> user process; firewire-core: tasklet -> user process.) This change introduces retries and delays after ack_busy_X into firewire-core's Config ROM reader, such that at least firewire-core's probing and /dev/fw* creation are successful. This still leaves the problem that userland processes are facing transaction failures. gscanbus's built-in retry routines deal with them successfully, but neither kino's nor dvgrab's do ever succeed. But at least DV capture with "dvgrab -noavc -card 0" works now. Live video preview in kino works too, but not actual capture. One way to prevent Configuration ROM reading failures in application programs is to modify libraw1394 to synthesize read responses by means of firewire-core's Configuration ROM cache. This would only leave CMP and FCP transaction failures as a potential problem source for applications. Reported-and-tested-by: Thomas Seilund Reported-and-tested-by: René Fritz Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases

2012-03-19T15:57:43Z

commit 9c1176b6a28850703ea6e3a0f0c703f6d6c61cd3 upstream. 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) or - 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 Reported-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: disable MSI on Ricoh controllers

2012-02-13T19:06:06Z

commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream. The PCIe device FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller [1180:e832] (prog-if 10 [OHCI]) is unable to access attached FireWire devices when MSI is enabled but works if MSI is disabled. http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html Hence add the "disable MSI" quirks flag for this device, or in fact for safety and simplicity for all current (R5U230, R5U231, R5U240) and future Ricoh PCIe 1394 controllers. Reported-by: Stefan Thomas Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: add reset packet quirk for SB Audigy

2012-02-13T19:06:06Z

commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream. The Audigy's SB1394 controller is actually from Texas Instruments and has the same bus reset packet generation bug, so it needs the same quirk entry. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: fix panic after rmmod with slow targets

2011-10-25T05:10:16Z

commit 0278ccd9d53e07c4e699432b2fed9de6c56f506c upstream. If firewire-sbp2 starts a login to a target that doesn't complete ORBs in a timely manner (and has to retry the login), and the module is removed before the operation times out, you end up with a null-pointer dereference and a kernel panic. [SR: This happens because sbp2_target_get/put() do not maintain module references. scsi_device_get/put() do, but at occasions like Chris describes one, nobody holds a reference to an SBP-2 sdev.] This patch cancels pending work for each unit in sbp2_remove(), which hopefully means there are no extra references around that prevent us from unloading. This fixes my crash. Signed-off-by: Chris Boot Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: add no MSI quirk for O2Micro controller

2011-10-03T18:40:33Z

commit f39aa30d7741f40ad964341e9243dbbd7f8ff057 upstream. This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 . An O2Micro PCI Express FireWire controller, "FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)" which is a combination device together with an SDHCI controller and some sort of storage controller, misses SBP-2 status writes from an attached FireWire HDD. This problem goes away if MSI is disabled for this FireWire controller. The device reportedly does not require QUIRK_CYCLE_TIMER. Signed-off-by: Ming Lei Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman