linux-toradex.git/drivers, branch v3.0.100

Tools: hv: verify origin of netlink connector message

2013-10-13T21:51:09+00:00

commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.

The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated from kernel.

CVE-2012-2669

Signed-off-by: Olaf Hering 
Signed-off-by: Marcus Meissner 
Signed-off-by: Sebastian Krahmer 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

tg3: fix length overflow in VPD firmware parsing

2013-10-13T21:51:08+00:00

commit 715230a44310a8cf66fbfb5a46f9a62a9b2de424 upstream.

Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
when present") introduced VPD parsing that contained a potential length
overflow.

Limit the hardware's reported firmware string length (max 255 bytes) to
stay inside the driver's firmware string length (32 bytes). On overflow,
truncate the formatted firmware string instead of potentially overwriting
portions of the tg3 struct.

http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf

-js: This fixes CVE-2013-1929.

Signed-off-by: Kees Cook 
Reported-by: Oded Horovitz 
Reported-by: Brad Spengler 
Cc: stable@vger.kernel.org
Cc: Matt Carlson 
Signed-off-by: David S. Miller 
Acked-by: Jeff Mahoney 
Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()

2013-10-13T21:51:08+00:00

commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.

This patch fixes the issues indicated by the test results that
ipmi_msg_handler() is invoked in atomic context.

BUG: scheduling while atomic: kipmi0/18933/0x10000100
Modules linked in: ipmi_si acpi_ipmi ...
CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
Call Trace:
   [] dump_stack+0x19/0x1b
 [] __schedule_bug+0x46/0x54
 [] __schedule+0x83/0x59c
 [] __cond_resched+0x22/0x2d
 [] _cond_resched+0x14/0x1d
 [] mutex_lock+0x11/0x32
 [] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
 [] ipmi_msg_handler+0x23/0x166 [ipmi_si]
 [] deliver_response+0x55/0x5a
 [] handle_new_recv_msgs+0xb67/0xc65
 [] ? read_tsc+0x9/0x19
 [] ? _raw_spin_lock_irq+0xa/0xc
 [] ipmi_thread+0x5c/0x146 [ipmi_si]
 ...

Also Tony Camuso says:

 We were getting occasional "Scheduling while atomic" call traces
 during boot on some systems. Problem was first seen on a Cisco C210
 but we were able to reproduce it on a Cisco c220m3. Setting
 CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
 tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.

 =================================
 [ INFO: inconsistent lock state ]
 2.6.32-415.el6.x86_64-debug-splck #1
 ---------------------------------
 inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
 ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&ipmi_device->tx_msg_lock){+.?...}, at: [] ipmi_msg_handler+0x71/0x126
 {SOFTIRQ-ON-W} state was registered at:
   [] __lock_acquire+0x63c/0x1570
   [] lock_acquire+0xa4/0x120
   [] __mutex_lock_common+0x4c/0x400
   [] mutex_lock_nested+0x4a/0x60
   [] acpi_ipmi_space_handler+0x11b/0x234
   [] acpi_ev_address_space_dispatch+0x170/0x1be

The fix implemented by this change has been tested by Tony:

 Tested the patch in a boot loop with lockdep debug enabled and never
 saw the problem in over 400 reboots.

Reported-and-tested-by: Tony Camuso 
Signed-off-by: Lv Zheng 
Reviewed-by: Huang Ying 
Signed-off-by: Rafael J. Wysocki 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice

2013-10-13T21:51:08+00:00

commit 677a31565692d596ef42ea589b53ba289abf4713 upstream.

The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
currently writes (optionally) and reads back up to 5 "ports" consisting
of 8 channels each.  It reads up to 32 1-bit channels but can only read
and write a whole port at once - it needs to handle up to 5 ports as the
first channel it reads might not be aligned on a port boundary.  It
breaks out of the loop early if the next port it handles is beyond the
final port on the card.  It also breaks out early on the 5th port in the
loop if the first channel was aligned.  Unfortunately, it doesn't check
that the current port it is dealing with belongs to the comedi subdevice
the `insn_bits` handler is acting on.  That's a bug.

Redo the `for` loop to terminate after the final port belonging to the
subdevice, changing the loop variable in the process to simplify things
a bit.  The `for` loop could now try and handle more than 5 ports if the
subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
ensures it will break out early after 4 or 5 ports (depending on whether
the first channel is aligned on a port boundary).  (`bitshift` will be
between -7 and 7 inclusive on the first iteration, increasing by 8 for
each subsequent operation.)

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

p54usb: add USB ID for Corega WLUSB2GTST USB adapter

2013-10-13T21:51:08+00:00

commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.

Added USB ID for Corega WLUSB2GTST USB adapter.

Reported-by: Joerg Kalisch 
Signed-off-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Align private space in rtl_priv struct

2013-10-13T21:51:08+00:00

commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream.

The private array at the end of the rtl_priv struct is not aligned.
On ARM architecture, this causes an alignment trap and is fixed by aligning
that array with __align(sizeof(void *)). That should properly align that
space according to the requirements of all architectures.

Reported-by: Jason Andrews 
Tested-by: Jason Andrews 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: Ignore card reader interface on Huawei E1750

2013-10-13T21:51:08+00:00

commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream.

Hi,

my Huawei 3G modem has an embedded Smart Card reader which causes
trouble when the modem is being detected (a bunch of "  (ttyUSBx):
open blocked by driver for more than 7 seconds!" in messages.log). This
trivial patch corrects the problem for me. The modem identifies itself
as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
description on the body says "Model E173u-1"

Signed-off-by: Michal Malý 
Cc: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman

esp_scsi: Fix tag state corruption when autosensing.

2013-10-13T21:51:08+00:00

[ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ]

Meelis Roos reports a crash in esp_free_lun_tag() in the presense
of a disk which has died.

The issue is that when we issue an autosense command, we do so by
hijacking the original command that caused the check-condition.

When we do so we clear out the ent->tag[] array when we issue it via
find_and_prep_issuable_command().  This is so that the autosense
command is forced to be issued non-tagged.

That is problematic, because it is the value of ent->tag[] which
determines whether we issued the original scsi command as tagged
vs. non-tagged (see esp_alloc_lun_tag()).

And that, in turn, is what trips up the sanity checks in
esp_free_lun_tag().  That function needs the original ->tag[] values
in order to free up the tag slot properly.

Fix this by remembering the original command's tag values, and
having esp_alloc_lun_tag() and esp_free_lun_tag() use them.

Reported-by: Meelis Roos 
Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ll_temac: Reset dma descriptors indexes on ndo_open

2013-10-13T21:51:07+00:00

[ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]

The dma descriptors indexes are only initialized on the probe function.

If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.

So an interface could be left in an usable state after ifdow/ifup.

This patch makes sure that the descriptors indexes are in a proper
status when the device is open.

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: Fix broken promiscuity reference counting issue

2013-10-13T21:51:07+00:00

[ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ]

Recently grabbed this report:
https://bugzilla.redhat.com/show_bug.cgi?id=1005567

Of an issue in which the bonding driver, with an attached vlan encountered the
following errors when bond0 was taken down and back up:

dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
device might be broken.

The error occurs because, during __bond_release_one, if we release our last
slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
notification.  With an attached vlan, the vlan may see that the vlan and bond
mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
we complete __bond_release_one, we use the current state of the bond flags to
determine if we should decrement the promiscuity of the releasing slave.  But
since the bond changed promiscuity state during the release operation, we
incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
to begin with, causing the above error

Fix is pretty simple, just cache the bonding flags at the start of the function
and use those when determining the need to set promiscuity.

This is also needed for the ALLMULTI flag

Reported-by: Mark Wu 
CC: Jay Vosburgh 
CC: Andy Gospodarek 
CC: Mark Wu 
CC: "David S. Miller" 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman