linux/drivers/firewire, branch v2.6.32.60

firewire: ohci: fix race in AR split packet handling

2010-12-09T21:26:50Z

commit a1f805e5e73a8fe166b71c6592d3837df0cd5e2e upstream. When handling an AR buffer that has been completely filled, we assumed that its descriptor will not be read by the controller and can be overwritten. However, when the last received packet happens to end at the end of the buffer, the controller might not yet have moved on to the next buffer and might read the branch address later. If we overwrite and free the page before that, the DMA context will either go dead because of an invalid Z value, or go off into some random memory. To fix this, ensure that the descriptor does not get overwritten by using only the actual buffer instead of the entire page for reassembling the split packet. Furthermore, to avoid freeing the page too early, move on to the next buffer only when some data in it guarantees that the controller has moved on. This should eliminate the remaining firewire-net problems. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix buffer overflow in AR split packet handling

2010-12-09T21:26:49Z

commit 85f7ffd5d2b320f73912b15fe8cef34bae297daf upstream. When the controller had to split a received asynchronous packet into two buffers, the driver tries to reassemble it by copying both parts into the first page. However, if size + rest > PAGE_SIZE, i.e., if the yet unhandled packets before the split packet, the split packet itself, and any received packets after the split packet are together larger than one page, then the memory after the first page would get overwritten. To fix this, do not try to copy the data of all unhandled packets at once, but copy the possibly needed data every time when handling a packet. This gets rid of most of the infamous crashes and data corruptions when using firewire-net. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: core: fix an information leak

2010-12-09T21:26:49Z

commit 137d9ebfdbaa45c01f9f0f6d5121ae6f1eb942bd upstream. If a device exposes a sparsely populated configuration ROM, firewire-core's sysfs interface and character device file interface showed random data in the gaps between config ROM blocks. Fix this by zero-initialization of the config ROM reader's scratch buffer. Signed-off-by: Stefan Richter Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

firewire: cdev: fix information leak

2010-12-09T21:26:48Z

commit 9cac00b8f0079d5d3d54ec4dae453d58dec30e7c upstream. A userspace client got to see uninitialized stack-allocated memory if it specified an _IOC_READ type of ioctl and an argument size larger than expected by firewire-core's ioctl handlers (but not larger than the core's union ioctl_arg). Fix this by clearing the requested buffer size to zero, but only at _IOR ioctls. This way, there is almost no runtime penalty to legitimate ioctls. The only legitimate _IOR is FW_CDEV_IOC_GET_CYCLE_TIMER with 12 or 16 bytes to memset. [Another way to fix this would be strict checking of argument size (and possibly direction) vs. command number. However, we then need a lookup table, and we need to allow for slight size deviations in case of 32bit userland on 64bit kernel.] Reported-by: Clemens Ladisch Signed-off-by: Stefan Richter [ Backported to 2.6.32 firewire core -maks ] Signed-off-by: maximilian attems Signed-off-by: Greg Kroah-Hartman

firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder

2010-07-05T18:11:04Z

commit 10389536742cefbedecb67a5b2906f155cf3a1c3 upstream. Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check whether the current IRM complies to 1394a-2000 or later. If not force a compliant node (e.g. itself) to become IRM. This was implemented in the older ieee1394 driver but not yet in firewire-core. An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM but neither 1394a-2000 IRM nor BM was now found to cause an interoperability bug: - Camcorder becomes root node when plugged in, hence gets IRM role. - firewire-core successfully contends for BM role, proceeds to perform gap count optimization and resets the bus. - Sony camcorder ignores presence of a BM (against the spec, this is a firmware bug), performs its idea of gap count optimization and resets the bus. - Preceding two steps are repeated endlessly, bus never settles, regular I/O is practically impossible. http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913 This is an interoperability regression from the old to the new drivers. Fix it indirectly by adding the 1394a IRM check. The spec suggests three and a half methods to determine 1394a compliance of a remote IRM; we choose the method of testing the Config_ROM.Bus_Info.generation field. This is data that firewire-core should have readily available at this point, i.e. does not require extra I/O. Reported-by: Clemens Ladisch (missing 1394a check) Reported-by: H. S. (issue with Sony DCR-TRV25) Tested-by: H. S. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: core: add_descriptor size check

2010-02-09T12:50:52Z

Backport of commit e300839da40e99581581c5d053a95a172651fec8 upstream. Presently, firewire-core only checks whether descriptors that are to be added by userspace drivers to the local node's config ROM do not exceed a size of 256 quadlets. However, the sum of the bare minimum ROM plus all descriptors (from firewire-core, from firewire-net, from userspace) must not exceed 256 quadlets. Otherwise, the bounds of a statically allocated buffer will be overwritten. If the kernel survives that, firewire-core will subsequently be unable to parse the local node's config ROM. (Note, userspace drivers can add descriptors only through device files of local nodes. These are usually only accessible by root, unlike device files of remote nodes which may be accessible to lesser privileged users.) Therefore add a test which takes the actual present and required ROM size into account for all descriptors of kernelspace and userspace drivers. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: fix crashes with TSB43AB23 on 64bit systems

2010-02-09T12:50:42Z

commit 7a481436787cbc932af6c407b317ac603969a242 upstream. Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located at physical addresses above the 31 bit address range (2 GB), the controller will overwrite random memory. With luck, this merely prevents video reception. With only a little less luck, the machine crashes. We use the same workaround here as with TSB43AB22/A: Switch off the dual buffer capability flag and use packet-per-buffer IR DMA instead. Another possible workaround would be to limit the coherent DMA mask to 31 bits. In Linux 2.6.33, this change serves effectively only as documentation since dual buffer mode is not used for any controller anymore. But somebody might want to re-enable it in the future to make use of features of dual buffer DMA that are not available in packet-per-buffer mode. In Linux 2.6.32 and older, this update is vital for anyone with this controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or audio applications. We have at least four reports: http://bugzilla.kernel.org/show_bug.cgi?id=13808 http://marc.info/?l=linux1394-user&m=126154279004083 https://bugzilla.redhat.com/show_bug.cgi?id=552142 http://marc.info/?l=linux1394-user&m=126432246128386 Reported-by: Paul Johnson Reported-by: Ronneil Camara Reported-by: G Zornetzer Reported-by: Mark Thompson Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

firewire: ohci: handle receive packets with a data length of zero

2009-12-18T22:02:57Z

commit 8c0c0cc2d9f4c523fde04bdfe41e4380dec8ee54 upstream. Queueing to receive an ISO packet with a payload length of zero silently does nothing in dualbuffer mode, and crashes the kernel in packet-per-buffer mode. Return an error in dualbuffer mode, because the DMA controller won't let us do what we want, and work correctly in packet-per-buffer mode. Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6

2009-11-30T21:58:23Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: ohci: pass correct iso xmit timestamps to core firewire: ohci: Make cycleMatch ISO transmission work

firewire: ohci: pass correct iso xmit timestamps to core

2009-11-20T23:56:47Z

Here is the final set of patches I used to get ffado to work with the new firewire stack. With these patches, I was able to start ardour and record from and playback to my PreSonus Inspire1394 from a (mostly) Fedora 12 system. Signed-off-by: Jay Fenlason Until now, firewire-ohci exposed only the transmit cycle of the last transmitted packet at each isochronous transmit complete event. This made it impossible for FFADO (FireWire audio drivers in userspace) to synchronize audio-out streams. The fix is to store the timestamp of each packet in the iso xmit event. As a bonus, the transfer status is stored too. Signed-off-by: Stefan Richter