linux-stable.git/drivers, branch linux-2.6.32.y

iw_cxgb3: Fix incorrectly returning error on success

2016-03-12T13:25:48+00:00

commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 upstream.

The cxgb3_*_send() functions return NET_XMIT_ values, which are
positive integers values. So don't treat positive return values
as an error.

Signed-off-by: Steve Wise 
Signed-off-by: Hariprasad Shenai 
Signed-off-by: Doug Ledford 
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD

2016-03-12T13:25:48+00:00

commit 73a203d2014f50d874b9e40083ad481ca70408e8 upstream.

The low level cxgb3 driver can return NET_XMIT_CN and friends.
The iw_cxgb3 driver should _not_ treat these as errors.

Signed-off-by: Steve Wise 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

scsi_dh_rdac: always retry MODE SELECT on command lock violation

2016-03-12T13:25:42+00:00

commit d2d06d4fe0f2cc2df9b17fefec96e6e1a1271d91 upstream.

If MODE SELECT returns with sense '05/91/36' (command lock violation)
it should always be retried without counting the number of retries.
During an HBA upgrade or similar circumstances one might see a flood
of MODE SELECT command from various HBAs, which will easily trigger
the sense code and exceed the retry count.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

saa7134-alsa: Only frees registered sound cards

2016-03-12T13:25:42+00:00

commit ac75fe5d8fe4a0bf063be18fb29684405279e79e upstream.

That prevents this bug:
[ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540
[ 2382.270013] IP: [] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] PGD 0
[ 2382.270013] Oops: 0002 [#1] SMP
[ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops]
[ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4
[ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012  05/14/2008
[ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000
[ 2382.270013] RIP: 0010:[]  [] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] RSP: 0018:ffff88003c767ea0  EFLAGS: 00010286
[ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260
[ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0
[ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412
[ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8
[ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0
[ 2382.270013] FS:  00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000
[ 2382.270013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0
[ 2382.270013] Stack:
[ 2382.270013]  000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8
[ 2382.270013]  ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0
[ 2382.270013]  ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c
[ 2382.270013] Call Trace:
[ 2382.270013]  [] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa]
[ 2382.270013]  [] SyS_delete_module+0x19c/0x1f0
[ 2382.270013]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d
[ 2382.270013] RIP  [] snd_card_free+0x36/0x70 [snd]
[ 2382.270013]  RSP 
[ 2382.270013] CR2: 0000000000000540

Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

tda1004x: only update the frontend properties if locked

2016-03-12T13:25:42+00:00

commit e8beb02343e7582980c6705816cd957cf4f74c7a upstream.

The tda1004x was updating the properties cache before locking.
If the device is not locked, the data at the registers are just
random values with no real meaning.

This caused the driver to fail with libdvbv5, as such library
calls GET_PROPERTY from time to time, in order to return the
DVB stats.

Tested with a saa7134 card 78:
	ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862

Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

SCSI: fix crashes in sd and sr runtime PM

2016-03-12T13:25:42+00:00

commit 13b4389143413a1f18127c07f72c74cad5b563e8 upstream.

Runtime suspend during driver probe and removal can cause problems.
The driver's runtime_suspend or runtime_resume callbacks may invoked
before the driver has finished binding to the device or after the
driver has unbound from the device.

This problem shows up with the sd and sr drivers, and can cause disk
or CD/DVD drives to become unusable as a result.  The fix is simple.
The drivers store a pointer to the scsi_disk or scsi_cd structure as
their private device data when probing is finished, so we simply have
to be sure to clear the private data during removal and test it during
runtime suspend/resume.

This fixes .

Signed-off-by: Alan Stern 
Reported-by: Paul Menzel 
Reported-by: Erich Schubert 
Reported-by: Alexandre Rossi 
Tested-by: Paul Menzel 
Tested-by: Erich Schubert 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: drop changes to sr as it doesn't support runtime PM]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

libata: disable forced PORTS_IMPL for >= AHCI 1.3

2016-03-12T13:25:42+00:00

commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 upstream.

Some early controllers incorrectly reported zero ports in PORTS_IMPL
register and the ahci driver fabricates PORTS_IMPL from the number of
ports in those cases.  This hasn't mattered but with the new nvme
controllers there are cases where zero PORTS_IMPL is valid and should
be honored.

Disable the workaround for >= AHCI 1.3.

Signed-off-by: Tejun Heo 
Reported-by: Andy Lutomirski 
Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com
Cc: Sergei Shtylyov 
Signed-off-by: Ben Hutchings 
[wt: file is drivers/ata/ahci.c in 2.6.32]
Signed-off-by: Willy Tarreau

PCI/AER: Flush workqueue on device remove to avoid use-after-free

2016-03-12T13:25:41+00:00

commit 4ae2182b1e3407de369f8c5d799543b7db74221b upstream.

A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
enqueues AER status information and schedules aer_isr() to dequeue and
process it.  When we remove a device, aer_remove() waits for the queue to
be empty, then frees the rpc struct.

But aer_isr() references the rpc struct after dequeueing and possibly
emptying the queue, which can cause a use-after-free error as in the
following scenario with two threads, aer_isr() on the left and a
concurrent aer_remove() on the right:

  Thread A                      Thread B
  --------                      --------
  aer_irq():
    rpc->prod_idx++
                                aer_remove():
                                  wait_event(rpc->prod_idx == rpc->cons_idx)
                                  # now blocked until queue becomes empty
  aer_isr():                      # ...
    rpc->cons_idx++               # unblocked because queue is now empty
    ...                           kfree(rpc)
    mutex_unlock(&rpc->rpc_mutex)

To prevent this problem, use flush_work() to wait until the last scheduled
instance of aer_isr() has completed before freeing the rpc struct in
aer_remove().

I reproduced this use-after-free by flashing a device FPGA and
re-enumerating the bus to find the new device.  With SLUB debug, this
crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
GPR25:

  pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
  Unable to handle kernel paging request for data at address 0x27ef9e3e
  Workqueue: events aer_isr
  GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
  NIP [602f5328] pci_walk_bus+0xd4/0x104

[bhelgaas: changelog, stable tag]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Ben Hutchings 
[wt: in 2.6.32, kfree() is called from aer_delete_rootport()]
Signed-off-by: Willy Tarreau

l2tp: fix another panic in pppol2tp

2016-03-12T13:25:41+00:00

Commit 3feec9095d1 ("l2tp: Fix oops in pppol2tp_xmit") was backported
into 2.6.32.16 to fix a possible null deref in pppol2tp. But the same
still exists in pppol2tp_sendmsg() possibly causing the same crash.
Note that this bug doesn't appear to have any other impact than crashing
the system, as the dereferenced pointer is only used to test a value
against a 3-bit mask, so it can hardly be abused for anything except
leaking one third of a bit of memory.

This issue doesn't exist upstream because the code was replaced in 2.6.35
and the new function l2tp_xmit_skb() performs the appropriate check.

Reported-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

2016-03-12T13:25:40+00:00

commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream.

ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).

However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.

Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.

Signed-off-by: Peter Hurley 
[bwh: Backported to 2.6.32: adjust filename]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau