6 years agoKEYS: Fix race between read and revoke
David Howells [Fri, 18 Dec 2015 01:34:26 +0000 (01:34 +0000)]
KEYS: Fix race between read and revoke

commit b4a1b4f5047e4f54e194681125c74c0aa64d637d upstream.

This fixes CVE-2015-7550.

There's a race between keyctl_read() and keyctl_revoke().  If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.

This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.

Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.

I think the bug was introduced with the original keyrings code.

This was discovered by a multithreaded test program generated by syzkaller
(  Here's a cleaned up version:

#include <sys/types.h>
#include <keyutils.h>
#include <pthread.h>
void *thr0(void *arg)
key_serial_t key = (unsigned long)arg;
return 0;
void *thr1(void *arg)
key_serial_t key = (unsigned long)arg;
char buffer[16];
keyctl_read(key, buffer, 16);
return 0;
int main()
key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
pthread_t th[5];
pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
pthread_join(th[0], 0);
pthread_join(th[1], 0);
pthread_join(th[2], 0);
pthread_join(th[3], 0);
return 0;

Build as:

cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

Run as:

while keyctl-race; do :; done

as it may need several iterations to crash the kernel.  The crash can be
summarised as:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffff81279b08>] user_read+0x56/0xa3
Call Trace:
 [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7
 [<ffffffff81277815>] SyS_keyctl+0x83/0xe0
 [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f

Reported-by: Dmitry Vyukov <>
Signed-off-by: David Howells <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: James Morris <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: fix invalid memory access in hub_activate()
Alan Stern [Wed, 16 Dec 2015 18:32:38 +0000 (13:32 -0500)]
USB: fix invalid memory access in hub_activate()

commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream.

Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be

Signed-off-by: Alan Stern <>
Reported-by: Alexandru Cornea <>
Tested-by: Alexandru Cornea <>
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: add prototype for hub_release() before first use]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: ipaq.c: fix a timeout loop
Dan Carpenter [Wed, 16 Dec 2015 11:06:37 +0000 (14:06 +0300)]
USB: ipaq.c: fix a timeout loop

commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream.

The code expects the loop to end with "retries" set to zero but, because
it is a post-op, it will end set to -1.  I have fixed this by moving the
decrement inside the loop.

Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.')
Signed-off-by: Dan Carpenter <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.
Konrad Rzeszutek Wilk [Mon, 2 Nov 2015 23:13:27 +0000 (18:13 -0500)]
xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.

commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 upstream.

commit f598282f51 ("PCI: Fix the NIU MSI-X problem in a better way")
teaches us that dealing with MSI-X can be troublesome.

Further checks in the MSI-X architecture shows that if the
PCI_COMMAND_MEMORY bit is turned of in the PCI_COMMAND we
may not be able to access the BAR (since they are memory regions).

Since the MSI-X tables are located in there.. that can lead
to us causing PCIe errors. Inhibit us performing any
operation on the MSI-X unless the MEMORY bit is set.

Note that Xen hypervisor with:
"x86/MSI-X: access MSI-X table only after having enabled MSI-X"
will return:
xen_pciback: 0000:0a:00.1: error -6 enabling MSI-X for guest 3!

When the generic MSI code tries to setup the PIRQ without
MEMORY bit set. Which means with later versions of Xen
(4.6) this patch is not neccessary.

This is part of XSA-157

Reviewed-by: Jan Beulich <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device has MSI(X) enabled.
Konrad Rzeszutek Wilk [Wed, 1 Apr 2015 14:49:47 +0000 (10:49 -0400)]
xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device has MSI(X) enabled.

commit 7cfb905b9638982862f0331b36ccaaca5d383b49 upstream.

Otherwise just continue on, returning the same values as
previously (return of 0, and op->result has the PIRQ value).

This does not change the behavior of XEN_PCI_OP_disable_msi[|x].

The pci_disable_msi or pci_disable_msix have the checks for
msi_enabled or msix_enabled so they will error out immediately.

However the guest can still call these operations and cause
us to disable the 'ack_intr'. That means the backend IRQ handler
for the legacy interrupt will not respond to interrupts anymore.

This will lead to (if the device is causing an interrupt storm)
for the Linux generic code to disable the interrupt line.

Naturally this will only happen if the device in question
is plugged in on the motherboard on shared level interrupt GSI.

This is part of XSA-157

Reviewed-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: Do not install an IRQ handler for MSI interrupts.
Konrad Rzeszutek Wilk [Mon, 2 Nov 2015 22:24:08 +0000 (17:24 -0500)]
xen/pciback: Do not install an IRQ handler for MSI interrupts.

commit a396f3a210c3a61e94d6b87ec05a75d0be2a60d0 upstream.

Otherwise an guest can subvert the generic MSI code to trigger
an BUG_ON condition during MSI interrupt freeing:

 for (i = 0; i < entry->nvec_used; i++)
        BUG_ON(irq_has_action(entry->irq + i));

Xen PCI backed installs an IRQ handler (request_irq) for
the dev->irq whenever the guest writes PCI_COMMAND_MEMORY
(or PCI_COMMAND_IO) to the PCI_COMMAND register. This is
done in case the device has legacy interrupts the GSI line
is shared by the backend devices.

To subvert the backend the guest needs to make the backend
to change the dev->irq from the GSI to the MSI interrupt line,
make the backend allocate an interrupt handler, and then command
the backend to free the MSI interrupt and hit the BUG_ON.

Since the backend only calls 'request_irq' when the guest
writes to the PCI_COMMAND register the guest needs to call
XEN_PCI_OP_enable_msi before any other operation. This will
cause the generic MSI code to setup an MSI entry and
populate dev->irq with the new PIRQ value.

Then the guest can write to PCI_COMMAND PCI_COMMAND_MEMORY
and cause the backend to setup an IRQ handler for dev->irq
(which instead of the GSI value has the MSI pirq). See

Then the guest disables the MSI: XEN_PCI_OP_disable_msi
which ends up triggering the BUG_ON condition in 'free_msi_irqs'
as there is an IRQ handler for the entry->irq (dev->irq).

Note that this cannot be done using MSI-X as the generic
code does not over-write dev->irq with the MSI-X PIRQ values.

The patch inhibits setting up the IRQ handler if MSI or
MSI-X (for symmetry reasons) code had been called successfully.

Xen PCIBack when it sets up the device for the guest consumption
ends up writting 0 to the PCI_COMMAND (see xen_pcibk_reset_device).
XSA-120 addendum patch removed that - however when upstreaming said
addendum we found that it caused issues with qemu upstream. That
has now been fixed in qemu upstream.

This is part of XSA-157

Reviewed-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X...
Konrad Rzeszutek Wilk [Mon, 2 Nov 2015 23:07:44 +0000 (18:07 -0500)]
xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled

commit 5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9 upstream.

The guest sequence of:

  a) XEN_PCI_OP_enable_msix
  b) XEN_PCI_OP_enable_msix

results in hitting an NULL pointer due to using freed pointers.

The device passed in the guest MUST have MSI-X capability.

The a) constructs and SysFS representation of MSI and MSI groups.
The b) adds a second set of them but adding in to SysFS fails (duplicate entry).
'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that
in a) pdev->msi_irq_groups is still set) and also free's ALL of the
MSI-X entries of the device (the ones allocated in step a) and b)).

The unwind code: 'free_msi_irqs' deletes all the entries and tries to
delete the pdev->msi_irq_groups (which hasn't been set to NULL).
However the pointers in the SysFS are already freed and we hit an
NULL pointer further on when 'strlen' is attempted on a freed pointer.

The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard
against that. The check for msi_enabled is not stricly neccessary.

This is part of XSA-157

Reviewed-by: David Vrabel <>
Reviewed-by: Jan Beulich <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: Return error on XEN_PCI_OP_enable_msi when device has MSI or MSI-X enabled
Konrad Rzeszutek Wilk [Fri, 3 Apr 2015 15:08:22 +0000 (11:08 -0400)]
xen/pciback: Return error on XEN_PCI_OP_enable_msi when device has MSI or MSI-X enabled

commit 56441f3c8e5bd45aab10dd9f8c505dd4bec03b0d upstream.

The guest sequence of:

 a) XEN_PCI_OP_enable_msi
 b) XEN_PCI_OP_enable_msi
 c) XEN_PCI_OP_disable_msi

results in hitting an BUG_ON condition in the msi.c code.

The MSI code uses an dev->msi_list to which it adds MSI entries.
Under the above conditions an BUG_ON() can be hit. The device
passed in the guest MUST have MSI capability.

The a) adds the entry to the dev->msi_list and sets msi_enabled.
The b) adds a second entry but adding in to SysFS fails (duplicate entry)
and deletes all of the entries from msi_list and returns (with msi_enabled
is still set).  c) pci_disable_msi passes the msi_enabled checks and hits:


and blows up.

The patch adds a simple check in the XEN_PCI_OP_enable_msi to guard
against that. The check for msix_enabled is not stricly neccessary.

This is part of XSA-157.

Reviewed-by: David Vrabel <>
Reviewed-by: Jan Beulich <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/pciback: Save xen_pci_op commands before processing it
Konrad Rzeszutek Wilk [Mon, 16 Nov 2015 17:40:48 +0000 (12:40 -0500)]
xen/pciback: Save xen_pci_op commands before processing it

commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 upstream.

Double fetch vulnerabilities that happen when a variable is
fetched twice from shared memory but a security check is only
performed the first time.

The xen_pcibk_do_op function performs a switch statements on the op->cmd
value which is stored in shared memory. Interestingly this can result
in a double fetch vulnerability depending on the performed compiler

This patch fixes it by saving the xen_pci_op command before
processing it. We also use 'barrier' to make sure that the
compiler does not perform any optimization.

This is part of XSA155.

Reviewed-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Jan Beulich <>
Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agoxen-blkback: only read request operation from shared ring once
Roger Pau Monné [Tue, 3 Nov 2015 16:34:09 +0000 (16:34 +0000)]
xen-blkback: only read request operation from shared ring once

commit 1f13d75ccb806260079e0679d55d9253e370ec8a upstream.

A compiler may load a switch statement value multiple times, which could
be bad when the value is in memory shared with the frontend.

When converting a non-native request to a native one, ensure that
src->operation is only loaded once by using READ_ONCE().

This is part of XSA155.

Signed-off-by: Roger Pau Monné <>
Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
[bwh: Backported to 3.2:
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxen-netback: use RING_COPY_REQUEST() throughout
David Vrabel [Fri, 30 Oct 2015 15:17:06 +0000 (15:17 +0000)]
xen-netback: use RING_COPY_REQUEST() throughout

commit 68a33bfd8403e4e22847165d149823a2e0e67c9c upstream.

Instead of open-coding memcpy()s and directly accessing Tx and Rx
requests, use the new RING_COPY_REQUEST() that ensures the local copy
is correct.

This is more than is strictly necessary for guest Rx requests since
only the id and gref fields are used and it is harmless if the
frontend modifies these.

This is part of XSA155.

Reviewed-by: Wei Liu <>
Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
[bwh: Backported to 3.2:
 - s/queue/vif/g
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxen-netback: don't use last request to determine minimum Tx credit
David Vrabel [Fri, 30 Oct 2015 15:16:01 +0000 (15:16 +0000)]
xen-netback: don't use last request to determine minimum Tx credit

commit 0f589967a73f1f30ab4ac4dd9ce0bb399b4d6357 upstream.

The last from guest transmitted request gives no indication about the
minimum amount of credit that the guest might need to send a packet
since the last packet might have been a small one.

Instead allow for the worst case 128 KiB packet.

This is part of XSA155.

Reviewed-by: Wei Liu <>
Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
[bwh: Backported to 3.2: s/queue/vif/g]
Signed-off-by: Ben Hutchings <>
6 years agoxen: Add RING_COPY_REQUEST()
David Vrabel [Fri, 30 Oct 2015 14:58:08 +0000 (14:58 +0000)]

commit 454d5d882c7e412b840e3c99010fe81a9862f6fb upstream.

Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected).  Safe usage of a request
generally requires taking a local copy.

Provide a RING_COPY_REQUEST() macro to use instead of
RING_GET_REQUEST() and an open-coded memcpy().  This takes care of
ensuring that the copy is done correctly regardless of any possible
compiler optimizations.

Use a volatile source to prevent the compiler from reordering or
omitting the copy.

This is part of XSA155.

Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
6 years agos390/dis: Fix handling of format specifiers
Michael Holzheu [Thu, 17 Dec 2015 18:06:02 +0000 (19:06 +0100)]
s390/dis: Fix handling of format specifiers

commit 272fa59ccb4fc802af28b1d699c2463db6a71bf7 upstream.

The print_insn() function returns strings like "lghi %r1,0". To escape the
'%' character in sprintf() a second '%' is used. For example "lghi %%r1,0"
is converted into "lghi %r1,0".

After print_insn() the output string is passed to printk(). Because format
specifiers like "%r" or "%f" are ignored by printk() this works by chance
most of the time. But for instructions with control registers like
"lctl %c6,%c6,780" this fails because printk() interprets "%c" as
character format specifier.

Fix this problem and escape the '%' characters twice.

For example "lctl %%%%c6,%%%%c6,780" is then converted by sprintf()
into "lctl %%c6,%%c6,780" and by printk() into "lctl %c6,%c6,780".

Signed-off-by: Michael Holzheu <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: drop the OPERAND_VR case]
Signed-off-by: Ben Hutchings <>
6 years agoftrace/scripts: Have recordmcount copy the object file
Steven Rostedt (Red Hat) [Tue, 15 Dec 2015 21:06:10 +0000 (16:06 -0500)]
ftrace/scripts: Have recordmcount copy the object file

commit a50bd43935586420fb75f4558369eb08566fac5e upstream.

Russell King found that he had weird side effects when compiling the kernel
with hard linked ccache. The reason was that recordmcount modified the
kernel in place via mmap, and when a file gets modified twice by
recordmcount, it will complain about it. To fix this issue, Russell wrote a
patch that checked if the file was hard linked more than once and would
unlink it if it was.

Linus Torvalds was not happy with the fact that recordmcount does this in
place modification. Instead of doing the unlink only if the file has two or
more hard links, it does the unlink all the time. In otherwords, it always
does a copy if it changed something. That is, it does the write out if a
change was made.

Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agonet: fix warnings in 'make htmldocs' by moving macro definition out of field declaration
Hannes Frederic Sowa [Mon, 14 Dec 2015 22:30:43 +0000 (23:30 +0100)]
net: fix warnings in 'make htmldocs' by moving macro definition out of field declaration

commit 7bbadd2d1009575dad675afc16650ebb5aa10612 upstream.

Docbook does not like the definition of macros inside a field declaration
and adds a warning. Move the definition out.

Fixes: 79462ad02e86180 ("net: add validation for the socket syscall protocol argument")
Reported-by: kbuild test robot <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: keep open-coding U8_MAX]
Signed-off-by: Ben Hutchings <>
6 years agoscripts: recordmcount: break hardlinks
Russell King [Fri, 11 Dec 2015 12:09:03 +0000 (12:09 +0000)]
scripts: recordmcount: break hardlinks

commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream.

recordmcount edits the file in-place, which can cause problems when
using ccache in hardlink mode.  Arrange for recordmcount to break a
hardlinked object.

Signed-off-by: Russell King <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agospi: fix parent-device reference leak
Johan Hovold [Mon, 14 Dec 2015 15:16:19 +0000 (16:16 +0100)]
spi: fix parent-device reference leak

commit 157f38f993919b648187ba341bfb05d0e91ad2f6 upstream.

Fix parent-device reference leak due to SPI-core taking an unnecessary
reference to the parent when allocating the master structure, a
reference that was never released.

Note that driver core takes its own reference to the parent when the
master device is registered.

Fixes: 49dce689ad4e ("spi doesn't need class_device")
Signed-off-by: Johan Hovold <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoser_gigaset: fix deallocation of platform device structure
Tilman Schmidt [Tue, 15 Dec 2015 17:11:30 +0000 (18:11 +0100)]
ser_gigaset: fix deallocation of platform device structure

commit 4c5e354a974214dfb44cd23fa0429327693bc3ea upstream.

When shutting down the device, the struct ser_cardstate must not be
kfree()d immediately after the call to platform_device_unregister()
since the embedded struct platform_device is still in use.
Move the kfree() call to the release method instead.

Signed-off-by: Tilman Schmidt <>
Fixes: 2869b23e4b95 ("drivers/isdn/gigaset: new M101 driver (v2)")
Reported-by: Sasha Levin <>
Signed-off-by: Paul Bolle <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agomISDN: fix a loop count
Dan Carpenter [Tue, 15 Dec 2015 10:07:52 +0000 (13:07 +0300)]
mISDN: fix a loop count

commit 40d24c4d8a7430aa4dfd7a665fa3faf3b05b673f upstream.

There are two issue here.
1)  cnt starts as maxloop + 1 so all these loops iterate one more time
    than intended.
2)  At the end of the loop we test for "if (maxloop && !cnt)" but for
    the first two loops, we end with cnt equal to -1.  Changing this to
    a pre-op means we end with cnt set to 0.

Fixes: cae86d4a4e56 ('mISDN: Add driver for Infineon ISDN chipset family')
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosh_eth: fix TX buffer byte-swapping
Sergei Shtylyov [Sun, 13 Dec 2015 18:27:04 +0000 (21:27 +0300)]
sh_eth: fix TX buffer byte-swapping

commit 3e2309937f1e5d538ff13da5fb8de41196927c61 upstream.

For the little-endian SH771x kernels the driver has to byte-swap the RX/TX
buffers,  however yet unset physcial address from the TX descriptor is used
to call sh_eth_soft_swap(). Use 'skb->data' instead...

Fixes: 31fcb99d9958 ("net: sh_eth: remove __flush_purge_region")
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly
Anssi Hannula [Sun, 13 Dec 2015 18:49:58 +0000 (20:49 +0200)]
ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

commit 42e3121d90f42e57f6dbd6083dff2f57b3ec7daa upstream.

AudioQuest DragonFly DAC reports a volume control range of 0..50
(0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
is obviously incorrect and would cause software using the dB information
in e.g. volume sliders to have a massive volume difference in 100..102%

Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
devices") added a dB range mapping for it with range 0..50 dB.

However, the actual volume mapping seems to be neither linear volume nor
linear dB scale, but instead quite close to the cubic mapping e.g.
alsamixer uses, with a range of approx. -53...0 dB.

Replace the previous quirk with a custom dB mapping based on some basic
output measurements, using a 10-item range TLV (which will still fit in

Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.

v2: incorporated Takashi Iwai's suggestion for the quirk application

Signed-off-by: Anssi Hannula <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: open-code usb_audio_info()]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: tlv: add DECLARE_TLV_DB_RANGE()
Clemens Ladisch [Sun, 20 Nov 2011 16:17:35 +0000 (17:17 +0100)]

commit bf1d1c9b6179faa3bc32cee882462bc8eebde25d upstream.

Add a DECLARE_TLV_DB_RANGE() macro so that dB range information
can be specified without having to count the items manually for

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: tlv: compute TLV_*_ITEM lengths automatically
Clemens Ladisch [Sun, 20 Nov 2011 15:22:24 +0000 (16:22 +0100)]
ALSA: tlv: compute TLV_*_ITEM lengths automatically

commit b5b9eb546762c4015c67c31364a6ec6f83fd2ada upstream.

Add helper macros with a little bit of preprocessor magic to
automatically compute the length of a TLV item.  This lets us avoid
having to compute this by hand, and will allow to use items that do
not use a fixed length.

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agotty: Fix GPF in flush_to_ldisc()
Peter Hurley [Fri, 27 Nov 2015 19:25:08 +0000 (14:25 -0500)]
tty: Fix GPF in flush_to_ldisc()

commit 9ce119f318ba1a07c29149301f1544b6c4bea52a upstream.

A line discipline which does not define a receive_buf() method can
can cause a GPF if data is ever received [1]. Oddly, this was known
to the author of n_tracesink in 2011, but never fixed.

[1] GPF report
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    PGD 3752d067 PUD 37a7b067 PMD 0
    Oops: 0010 [#1] SMP KASAN
    Modules linked in:
    CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: events_unbound flush_to_ldisc
    task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000
    RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
    RSP: 0018:ffff88006db67b50  EFLAGS: 00010246
    RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102
    RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388
    RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0
    R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000
    R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8
    FS:  0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0
     ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000
     ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90
     ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078
    Call Trace:
     [<ffffffff8127cf91>] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030
     [<ffffffff8127df14>] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162
     [<ffffffff8128faaf>] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302
     [<ffffffff852a7c2f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
    Code:  Bad RIP value.
    RIP  [<          (null)>]           (null)
     RSP <ffff88006db67b50>
    CR2: 0000000000000000
    ---[ end trace a587f8947e54d6ea ]---

Reported-by: Dmitry Vyukov <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoses: fix additional element traversal bug
James Bottomley [Fri, 11 Dec 2015 17:16:38 +0000 (09:16 -0800)]
ses: fix additional element traversal bug

commit 5e1033561da1152c57b97ee84371dba2b3d64c25 upstream.

KASAN found that our additional element processing scripts drop off
the end of the VPD page into unallocated space.  The reason is that
not every element has additional information but our traversal
routines think they do, leading to them expecting far more additional
information than is present.  Fix this by adding a gate to the
traversal routine so that it only processes elements that are expected
to have additional information (list is in SES-2 section
Additional Element Status diagnostic page overview)

Reported-by: Pavel Tikhomirov <>
Tested-by: Pavel Tikhomirov <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agoses: Fix problems with simple enclosures
James Bottomley [Tue, 8 Dec 2015 17:00:31 +0000 (09:00 -0800)]
ses: Fix problems with simple enclosures

commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd upstream.

Simple enclosure implementations (mostly USB) are allowed to return only
page 8 to every diagnostic query.  That really confuses our
implementation because we assume the return is the page we asked for and
end up doing incorrect offsets based on bogus information leading to
accesses outside of allocated ranges.  Fix that by checking the page
code of the return and giving an error if it isn't the one we asked for.
This should fix reported bugs with USB storage by simply refusing to
attach to enclosures that behave like this.  It's also good defensive
practise now that we're starting to see more USB enclosures.

Reported-by: Andrea Gelmini <>
Reviewed-by: Ewan D. Milne <>
Reviewed-by: Tomas Henzl <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agorfkill: copy the name into the rfkill struct
Johannes Berg [Thu, 10 Dec 2015 09:37:51 +0000 (10:37 +0100)]
rfkill: copy the name into the rfkill struct

commit b7bb110008607a915298bf0f47d25886ecb94477 upstream.

Some users of rfkill, like NFC and cfg80211, use a dynamic name when
allocating rfkill, in those cases dev_name(). Therefore, the pointer
passed to rfkill_alloc() might not be valid forever, I specifically
found the case that the rfkill name was quite obviously an invalid
pointer (or at least garbage) when the wiphy had been renamed.

Fix this by making a copy of the rfkill name in rfkill_alloc().

Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
6 years agocrypto: skcipher - Copy iv from desc even for 0-len walks
Jason A. Donenfeld [Sun, 6 Dec 2015 01:51:37 +0000 (02:51 +0100)]
crypto: skcipher - Copy iv from desc even for 0-len walks

commit 70d906bc17500edfa9bdd8c8b7e59618c7911613 upstream.

Some ciphers actually support encrypting zero length plaintexts. For
example, many AEAD modes support this. The resulting ciphertext for
those winds up being only the authentication tag, which is a result of
the key, the iv, the additional data, and the fact that the plaintext
had zero length. The blkcipher constructors won't copy the IV to the
right place, however, when using a zero length input, resulting in
some significant problems when ciphers call their initialization
routines, only to find that the ->iv parameter is uninitialized. One
such example of this would be using chacha20poly1305 with a zero length
input, which then calls chacha20, which calls the key setup routine,
which eventually OOPSes due to the uninitialized ->iv member.

Signed-off-by: Jason A. Donenfeld <>
Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agovideo: fbdev: fsl: Fix kernel crash when diu_ops is not implemented
Wang Dongsheng [Thu, 3 Dec 2015 01:54:12 +0000 (09:54 +0800)]
video: fbdev: fsl: Fix kernel crash when diu_ops is not implemented

commit acfc1cc13fe5bc6d7a10afa624f1e560850ddad3 upstream.

If diu_ops is not implemented on platform, kernel will access a NULL
pointer. We need to check this pointer in DIU initialization.

Signed-off-by: Wang Dongsheng <>
Acked-by: Timur Tabi <>
Signed-off-by: Tomi Valkeinen <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoipv6: sctp: fix lockdep splat in sctp_v6_get_dst()
Eric Dumazet [Mon, 7 Dec 2015 16:25:21 +0000 (08:25 -0800)]
ipv6: sctp: fix lockdep splat in sctp_v6_get_dst()

commit 69ce6487dcd364245a3d26322fc8f4ffd1e8d947 upstream.

While cooking the sctp np->opt rcu fixes, I forgot to move
one rcu_read_unlock() after the added rcu_dereference() in

This gave lockdep warnings reported by Dave Jones.

Fixes: c836a8ba9386 ("ipv6: sctp: add rcu protection around np->opt")
Reported-by: Dave Jones <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agosctp: start t5 timer only when peer rwnd is 0 and local state is SHUTDOWN_PENDING
lucien [Sat, 5 Dec 2015 07:35:36 +0000 (15:35 +0800)]
sctp: start t5 timer only when peer rwnd is 0 and local state is SHUTDOWN_PENDING

commit 8a0d19c5ed417c78d03f4e0fa7215e58c40896d8 upstream.

when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
state, if B neither claim his rwnd is 0 nor send SACK for this data, A
will keep retransmitting this data until t5 timeout, Max.Retrans times
can't work anymore, which is bad.

if B's rwnd is not 0, it should send abort after Max.Retrans times, only
when B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A
will start t5 timer, which is also commit f8d960524328 ("sctp: Enforce
retransmission limit during shutdown") means, but it lacks the condition
peer rwnd == 0.

so fix it by adding a bit (zero_window_announced) in peer to record if
the last rwnd is 0. If it was, zero_window_announced will be set. and use
this bit to decide if start t5 timer when local.state is SHUTDOWN_PENDING.

Fixes: commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
Signed-off-by: Xin Long <>
Signed-off-by: Marcelo Ricardo Leitner <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: change sack_needed to bitfield as done earlier upstream]
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.75 v3.2.75
Ben Hutchings [Wed, 30 Dec 2015 02:26:04 +0000 (02:26 +0000)]
Linux 3.2.75

6 years agoppp, slip: Validate VJ compression slot parameters completely
Ben Hutchings [Sun, 1 Nov 2015 16:22:53 +0000 (16:22 +0000)]
ppp, slip: Validate VJ compression slot parameters completely

commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae upstream.

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust indentation]

6 years agoisdn_ppp: Add checks for allocation failure in isdn_ppp_open()
Ben Hutchings [Sun, 1 Nov 2015 16:21:24 +0000 (16:21 +0000)]
isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 upstream.

Compile-tested only.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
6 years agoaf_unix: fix a fatal race with bit fields
Eric Dumazet [Wed, 1 May 2013 05:24:03 +0000 (05:24 +0000)]
af_unix: fix a fatal race with bit fields

commit 60bc851ae59bfe99be6ee89d6bc50008c85ec75d upstream.

Using bit fields is dangerous on ppc64/sparc64, as the compiler [1]
uses 64bit instructions to manipulate them.
If the 64bit word includes any atomic_t or spinlock_t, we can lose
critical concurrent changes.

This is happening in af_unix, where unix_sk(sk)->gc_candidate/
gc_maybe_cycle/lock share the same 64bit word.

This leads to fatal deadlock, as one/several cpus spin forever
on a spinlock that will never be available again.

A safer way would be to use a long to store flags.
This way we are sure compiler/arch wont do bad things.

As we own unix_gc_lock spinlock when clearing or setting bits,
we can use the non atomic __set_bit()/__clear_bit().

recursion_level can share the same 64bit location with the spinlock,
as it is set only with this spinlock held.

[1] bug fixed in gcc-4.8.0 :

Reported-by: Ambrose Feinstein <>
Signed-off-by: Eric Dumazet <>
Cc: Benjamin Herrenschmidt <>
Cc: Paul Mackerras <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoaf_unix: Revert 'lock_interruptible' in stream receive code
Rainer Weikusat [Wed, 16 Dec 2015 20:09:25 +0000 (20:09 +0000)]
af_unix: Revert 'lock_interruptible' in stream receive code

[ Upstream commit 3822b5c2fc62e3de8a0f33806ff279fb7df92432 ]

With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM
receive code was changed from using mutex_lock(&u->readlock) to
mutex_lock_interruptible(&u->readlock) to prevent signals from being
delayed for an indefinite time if a thread sleeping on the mutex
happened to be selected for handling the signal. But this was never a
problem with the stream receive code (as opposed to its datagram
counterpart) as that never went to sleep waiting for new messages with the
mutex held and thus, wouldn't cause secondary readers to block on the
mutex waiting for the sleeping primary reader. As the interruptible
locking makes the code more complicated in exchange for no benefit,
change it back to using mutex_lock.

Signed-off-by: Rainer Weikusat <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agobluetooth: Validate socket address length in sco_sock_bind().
David S. Miller [Tue, 15 Dec 2015 20:39:08 +0000 (15:39 -0500)]
bluetooth: Validate socket address length in sco_sock_bind().

[ Upstream commit 5233252fce714053f0151680933571a2da9cbfb4 ]

Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agopptp: verify sockaddr_len in pptp_bind() and pptp_connect()
WANG Cong [Mon, 14 Dec 2015 21:48:36 +0000 (13:48 -0800)]
pptp: verify sockaddr_len in pptp_bind() and pptp_connect()

[ Upstream commit 09ccfd238e5a0e670d8178cf50180ea81ae09ae1 ]

Reported-by: Dmitry Vyukov <>
Signed-off-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosh_eth: fix kernel oops in skb_put()
Sergei Shtylyov [Thu, 3 Dec 2015 22:45:40 +0000 (01:45 +0300)]
sh_eth: fix kernel oops in skb_put()

[ Upstream commit 248be83dcb3feb3f6332eb3d010a016402138484 ]

In a low memory situation the following kernel oops occurs:

Unable to handle kernel NULL pointer dereference at virtual address 00000050
pgd = 8490c000
[00000050] *pgd=4651e831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.4-at16 #9)
PC is at skb_put+0x10/0x98
LR is at sh_eth_poll+0x2c8/0xa10
pc : [<8035f780>]    lr : [<8028bf50>]    psr: 60000113
sp : 84eb1a90  ip : 84eb1ac8  fp : 84eb1ac4
r10: 0000003f  r9 : 000005ea  r8 : 00000000
r7 : 00000000  r6 : 940453b0  r5 : 00030000  r4 : 9381b180
r3 : 00000000  r2 : 00000000  r1 : 000005ea  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 4248c059  DAC: 00000015
Process klogd (pid: 2046, stack limit = 0x84eb02e8)

This is  because netdev_alloc_skb() fails and 'mdp->rx_skbuff[entry]' is left
NULL but sh_eth_rx() later  uses it without checking.  Add such check...

Reported-by: Yasushi SHOJI <>
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: add validation for the socket syscall protocol argument
Hannes Frederic Sowa [Mon, 14 Dec 2015 21:03:39 +0000 (22:03 +0100)]
net: add validation for the socket syscall protocol argument

[ Upstream commit 79462ad02e861803b3840cc782248c7359451cd9 ]

郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

int socket_fd;
struct sockaddr_in addr;
addr.sin_port = 0;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_family = 10;

socket_fd = socket(10,3,0x40000000);
connect(socket_fd , &addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
kernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
kernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110
kernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
kernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10
kernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

CVE: CVE-2015-8543
Cc: Cong Wang <>
Reported-by: 郭永刚 <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: open-code U8_MAX]
Signed-off-by: Ben Hutchings <>
6 years agoipv6: sctp: clone options to avoid use after free
Eric Dumazet [Wed, 9 Dec 2015 15:25:06 +0000 (07:25 -0800)]
ipv6: sctp: clone options to avoid use after free

[ Upstream commit 9470e24f35ab81574da54e69df90c1eb4a96b43f ]

SCTP is lacking proper np->opt cloning at accept() time.

TCP and DCCP use ipv6_dup_options() helper, do the same
in SCTP.

We might later factorize this code in a common helper to avoid
future mistakes.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Eric Dumazet <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosctp: update the netstamp_needed counter when copying sockets
Marcelo Ricardo Leitner [Fri, 4 Dec 2015 17:14:04 +0000 (15:14 -0200)]
sctp: update the netstamp_needed counter when copying sockets

[ Upstream commit 01ce63c90170283a9855d1db4fe81934dddce648 ]

Dmitry Vyukov reported that SCTP was triggering a WARN on socket destroy
related to disabling sock timestamp.

When SCTP accepts an association or peel one off, it copies sock flags
but forgot to call net_enable_timestamp() if a packet timestamping flag
was copied, leading to extra calls to net_disable_timestamp() whenever
such clones were closed.

The fix is to call net_enable_timestamp() whenever we copy a sock with
that flag on, like tcp does.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Marcelo Ricardo Leitner <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: SK_FLAGS_TIMESTAMP is newly defined]
Signed-off-by: Ben Hutchings <>
6 years agoatl1c: Improve driver not to do order 4 GFP_ATOMIC allocation
Pavel Machek [Fri, 4 Dec 2015 08:50:00 +0000 (09:50 +0100)]
atl1c: Improve driver not to do order 4 GFP_ATOMIC allocation

[ Upstream commit f2a3771ae8aca879c32336c76ad05a017629bae2 ]

atl1c driver is doing order-4 allocation with GFP_ATOMIC
priority. That often breaks  networking after resume. Switch to
GFP_KERNEL. Still not ideal, but should be significantly better.

atl1c_setup_ring_resources() is called from .open() function, and
already uses GFP_KERNEL, so this change is safe.

Signed-off-by: Pavel Machek <>
Acked-by: Michal Hocko <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoipv6: sctp: implement sctp_v6_destroy_sock()
Eric Dumazet [Tue, 1 Dec 2015 15:20:07 +0000 (07:20 -0800)]
ipv6: sctp: implement sctp_v6_destroy_sock()

[ Upstream commit 602dd62dfbda3e63a2d6a3cbde953ebe82bf5087 ]

Dmitry Vyukov reported a memory leak using IPV6 SCTP sockets.

We need to call inet6_destroy_sock() to properly release
inet6 specific fields.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Eric Dumazet <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoipv6: add complete rcu protection around np->opt
Eric Dumazet [Mon, 30 Nov 2015 03:37:57 +0000 (19:37 -0800)]
ipv6: add complete rcu protection around np->opt

[ Upstream commit 45f6fad84cc305103b28d73482b344d7f5b76f39 ]

This patch addresses multiple problems :

UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions
while socket is not locked : Other threads can change np->opt
concurrently. Dmitry posted a syzkaller
( program desmonstrating

Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock()
and dccp_v6_request_recv_sock() also need to use RCU protection
to dereference np->opt once (before calling ipv6_dup_options())

This patch adds full RCU protection to np->opt

Reported-by: Dmitry Vyukov <>
Signed-off-by: Eric Dumazet <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop changes to l2tp
 - Fix an additional use of np->opt in tcp_v6_send_synack()
 - Fold in commit 43264e0bd963 ("ipv6: remove unnecessary codes in tcp_ipv6.c")
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodccp: remove unnecessary codes in ipv6.c
RongQing.Li [Sun, 1 Jul 2012 17:19:00 +0000 (17:19 +0000)]
dccp: remove unnecessary codes in ipv6.c

commit 0979e465c5ab205b63a1c1820fe833f396a120f0 upstream.

opt always equals np->opts, so it is meaningless to define opt, and
check if opt does not equal np->opts and then try to free opt.

Signed-off-by: RongQing.Li <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoipv6: distinguish frag queues by device for multicast and link-local packets
Michal Kubeček [Tue, 24 Nov 2015 14:07:11 +0000 (15:07 +0100)]
ipv6: distinguish frag queues by device for multicast and link-local packets

[ Upstream commit 264640fc2c5f4f913db5c73fa3eb1ead2c45e9d7 ]

If a fragmented multicast packet is received on an ethernet device which
has an active macvlan on top of it, each fragment is duplicated and
received both on the underlying device and the macvlan. If some
fragments for macvlan are processed before the whole packet for the
underlying device is reassembled, the "overlapping fragments" test in
ip6_frag_queue() discards the whole fragment queue.

To resolve this, add device ifindex to the search key and require it to
match reassembling multicast packets and packets to link-local

Note: similar patch has been already submitted by Yoshifuji Hideaki in

but got lost and forgotten for some reason.

Signed-off-by: Michal Kubecek <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: ipmr: fix static mfc/dev leaks on table destruction
Nikolay Aleksandrov [Fri, 20 Nov 2015 12:54:19 +0000 (13:54 +0100)]
net: ipmr: fix static mfc/dev leaks on table destruction

[ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ]

When destroying an mrt table the static mfc entries and the static
devices are kept, which leads to devices that can never be destroyed
(because of refcnt taken) and leaked memory, for example:
unreferenced object 0xffff880034c144c0 (size 192):
  comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
  hex dump (first 32 bytes):
    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
    [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300
    [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910
    [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0
    [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0
    [<ffffffff81564e13>] raw_setsockopt+0x33/0x90
    [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20
    [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0
    [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
    [<ffffffffffffffff>] 0xffffffffffffffff

Make sure that everything is cleaned on netns destruction.

Signed-off-by: Nikolay Aleksandrov <>
Reviewed-by: Cong Wang <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet, scm: fix PaX detected msg_controllen overflow in scm_detach_fds
Daniel Borkmann [Thu, 19 Nov 2015 23:11:56 +0000 (00:11 +0100)]
net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds

[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]

David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:

(Already fixed in later grsecurity versions by Brad and PaX Team.)

[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
               cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ #7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153]  ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162]  ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169]  ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190]  [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200]  [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209]  [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220]  [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228]  [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236]  [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243]  [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248]  [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257]  [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263]  [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271]  [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85

Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.

In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.

When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():

  int cmlen = CMSG_LEN(i * sizeof(int));  <--- cmlen w/o tail-padding
  err = put_user(SOL_SOCKET, &cm->cmsg_level);
  if (!err)
    err = put_user(SCM_RIGHTS, &cm->cmsg_type);
  if (!err)
    err = put_user(cmlen, &cm->cmsg_len);
  if (!err) {
    cmlen = CMSG_SPACE(i * sizeof(int));  <--- cmlen w/ 4 byte extra tail-padding
    msg->msg_control += cmlen;
    msg->msg_controllen -= cmlen;         <--- iff no tail-padding space here ...
  }                                            ... wrap-around

F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.

In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.

In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen

Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).

Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!

Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).

Long time ago, Wei Yongjun fixed something related in commit 1ac70e7ad24a
("[NET]: Fix function put_cmsg() which may cause usr application memory

RFC3542, section 20.2. says:

  The fields shown as "XX" are possible padding, between the cmsghdr
  structure and the data, and between the data and the next cmsghdr
  structure, if required by the implementation. While sending an
  application may or may not include padding at the end of last
  ancillary data in msg_controllen and implementations must accept both
  as valid. On receiving a portable application must provide space for
  padding at the end of the last ancillary data as implementations may
  copy out the padding at the end of the control message buffer and
  include it in the received msg_controllen. When recvmsg() is called
  if msg_controllen is too small for all the ancillary data items
  including any trailing padding after the last item an implementation
  may set MSG_CTRUNC.

Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7ad24a to avoid an overflow.

Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).

No Fixes tag this time as pre 2002 (that is, pre history tree).

Reported-by: David Sterba <>
Reported-by: HacKurx <>
Cc: PaX Team <>
Cc: Emese Revfy <>
Cc: Brad Spengler <>
Cc: Wei Yongjun <>
Cc: Eric Dumazet <>
Reviewed-by: Hannes Frederic Sowa <>
Signed-off-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agotcp: initialize tp->copied_seq in case of cross SYN connection
Eric Dumazet [Thu, 26 Nov 2015 16:18:14 +0000 (08:18 -0800)]
tcp: initialize tp->copied_seq in case of cross SYN connection

[ Upstream commit 142a2e7ece8d8ac0e818eb2c91f99ca894730e2a ]

Dmitry provided a syzkaller (
generated program that triggers the WARNING at
net/ipv4/tcp.c:1729 in tcp_recvmsg() :

WARN_ON(tp->copied_seq != tp->rcv_nxt &&
        !(flags & (MSG_PEEK | MSG_TRUNC)));

His program is specifically attempting a Cross SYN TCP exchange,
that we support (for the pleasure of hackers ?), but it looks we
lack proper tcp->copied_seq initialization.

Thanks again Dmitry for your report and testings.

Signed-off-by: Eric Dumazet <>
Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosnmp: Remove duplicate OUTMCAST stat increment
Neil Horman [Mon, 16 Nov 2015 18:09:10 +0000 (13:09 -0500)]
snmp: Remove duplicate OUTMCAST stat increment

[ Upstream commit 41033f029e393a64e81966cbe34d66c6cf8a2e7e ]

the OUTMCAST stat is double incremented, getting bumped once in the mcast code
itself, and again in the common ip output path.  Remove the mcast bump, as its
not needed

Validated by the reporter, with good results

Signed-off-by: Neil Horman <>
Reported-by: Claus Jensen <>
CC: Claus Jensen <>
CC: David Miller <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosh64: fix __NR_fgetxattr
Dmitry V. Levin [Fri, 11 Dec 2015 21:41:06 +0000 (13:41 -0800)]
sh64: fix __NR_fgetxattr

commit 2d33fa1059da4c8e816627a688d950b613ec0474 upstream.

According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr
has to be defined to 259, but it doesn't.  Instead, it's defined to 269,
which is of course used by another syscall, __NR_sched_setaffinity in this

This bug was found by strace test suite.

Signed-off-by: Dmitry V. Levin <>
Acked-by: Geert Uytterhoeven <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agomm: hugetlb: call huge_pte_alloc() only if ptep is null
Naoya Horiguchi [Fri, 11 Dec 2015 21:40:49 +0000 (13:40 -0800)]
mm: hugetlb: call huge_pte_alloc() only if ptep is null

commit 0d777df5d8953293be090d9ab5a355db893e8357 upstream.

Currently at the beginning of hugetlb_fault(), we call huge_pte_offset()
and check whether the obtained *ptep is a migration/hwpoison entry or
not.  And if not, then we get to call huge_pte_alloc().  This is racy
because the *ptep could turn into migration/hwpoison entry after the
huge_pte_offset() check.  This race results in BUG_ON in

We don't have to call huge_pte_alloc() when the huge_pte_offset()
returns non-NULL, so let's fix this bug with moving the code into else

Note that the *ptep could turn into a migration/hwpoison entry after
this block, but that's not a problem because we have another
!pte_present check later (we never go into hugetlb_no_page() in that

Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
Signed-off-by: Naoya Horiguchi <>
Acked-by: Hillf Danton <>
Acked-by: David Rientjes <>
Cc: Hugh Dickins <>
Cc: Dave Hansen <>
Cc: Mel Gorman <>
Cc: Joonsoo Kim <>
Cc: Mike Kravetz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress
Michal Hocko [Fri, 11 Dec 2015 21:40:32 +0000 (13:40 -0800)]
mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress

commit 373ccbe5927034b55bdc80b0f8b54d6e13fe8d12 upstream.

Tetsuo Handa has reported that the system might basically livelock in
OOM condition without triggering the OOM killer.

The issue is caused by internal dependency of the direct reclaim on
vmstat counter updates (via zone_reclaimable) which are performed from
the workqueue context.  If all the current workers get assigned to an
allocation request, though, they will be looping inside the allocator
trying to reclaim memory but zone_reclaimable can see stalled numbers so
it will consider a zone reclaimable even though it has been scanned way
too much.  WQ concurrency logic will not consider this situation as a
congested workqueue because it relies that worker would have to sleep in
such a situation.  This also means that it doesn't try to spawn new
workers or invoke the rescuer thread if the one is assigned to the

In order to fix this issue we need to do two things.  First we have to
let wq concurrency code know that we are in trouble so we have to do a
short sleep.  In order to prevent from issues handled by 0e093d99763e
("writeback: do not sleep on the congestion queue if there are no
congested BDIs or if significant congestion is not being encountered in
the current zone") we limit the sleep only to worker threads which are
the ones of the interest anyway.

The second thing to do is to create a dedicated workqueue for vmstat and
mark it WQ_MEM_RECLAIM to note it participates in the reclaim and to
have a spare worker thread for it.

Signed-off-by: Michal Hocko <>
Reported-by: Tetsuo Handa <>
Cc: Tejun Heo <>
Cc: Cristopher Lameter <>
Cc: Joonsoo Kim <>
Cc: Arkadiusz Miskiewicz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoparisc iommu: fix panic due to trying to allocate too large region
Mikulas Patocka [Mon, 30 Nov 2015 19:47:46 +0000 (14:47 -0500)]
parisc iommu: fix panic due to trying to allocate too large region

commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.

When using the Promise TX2+ SATA controller on PA-RISC, the system often
crashes with kernel panic, for example just writing data with the dd
utility will make it crash.

Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
 [<000000004021497c>] show_stack+0x14/0x20
 [<0000000040410bf0>] dump_stack+0x88/0x100
 [<000000004023978c>] panic+0x124/0x360
 [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
 [<0000000040453150>] sba_map_sg+0x260/0x5b8
 [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
 [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
 [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
 [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
 [<000000004049da34>] scsi_request_fn+0x6e4/0x970
 [<00000000403e95a8>] __blk_run_queue+0x40/0x60
 [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
 [<000000004049a534>] scsi_run_queue+0x2a4/0x360
 [<000000004049be68>] scsi_end_request+0x1a8/0x238
 [<000000004049de84>] scsi_io_completion+0xfc/0x688
 [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0

The cause of the crash is not exhaustion of the IOMMU space, there is
plenty of free pages. The function sba_alloc_range is called with size
0x11000, thus the pages_needed variable is 0x11. The function
sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

The function sba_search_bitmap attempts to allocate 17 pages that must not
cross 16-page boundary - it can't satisfy this requirement
(iommu_is_span_boundary always returns true) and fails even if there are
many free entries in the IOMMU space.

How did it happen that we try to allocate 17 pages that don't cross
16-page boundary? The cause is in the function iommu_coalesce_chunks. This
function tries to coalesce adjacent entries in the scatterlist. The
function does several checks if it may coalesce one entry with the next,
one of those checks is this:

if (startsg->length + dma_len > max_seg_size)

When it finishes coalescing adjacent entries, it allocates the mapping:

sg_dma_len(contig_sg) = dma_len;
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
| dma_offset;

It is possible that (startsg->length + dma_len > max_seg_size) is false
(we are just near the 0x10000 max_seg_size boundary), so the funcion
decides to coalesce this entry with the next entry. When the coalescing
succeeds, the function performs
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
to allocate 17 pages for a device that must not cross 16-page boundary.

To fix the bug, we must make sure that dma_len after addition of
dma_offset and alignment doesn't cross the segment boundary. I.e. change
if (startsg->length + dma_len > max_seg_size)
if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)

This patch makes this change (it precalculates max_seg_boundary at the
beginning of the function iommu_coalesce_chunks). I also added a check
that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
not needed for Promise TX2+ SATA, but it may be needed for other devices
that have dma_get_seg_boundary lower than dma_get_max_seg_size).

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
6 years agovgaarb: fix signal handling in vga_get()
Kirill A. Shutemov [Mon, 30 Nov 2015 02:17:31 +0000 (04:17 +0200)]
vgaarb: fix signal handling in vga_get()

commit 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e upstream.

There are few defects in vga_get() related to signal hadning:

  - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE

  - if we found pending signal we must remove ourself from wait queue
    and change task state back to running;

  - -ERESTARTSYS is more appropriate, I guess.

Signed-off-by: Kirill A. Shutemov <>
Reviewed-by: David Herrmann <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
6 years agodm btree: fix bufio buffer leaks in dm_btree_del() error path
Joe Thornber [Thu, 10 Dec 2015 14:37:53 +0000 (14:37 +0000)]
dm btree: fix bufio buffer leaks in dm_btree_del() error path

commit ed8b45a3679eb49069b094c0711b30833f27c734 upstream.

If dm_btree_del()'s call to push_frame() fails, e.g. due to
btree_node_validator finding invalid metadata, the dm_btree_del() error
path must unlock all frames (which have active dm-bufio buffers) that
were pushed onto the del_stack.

Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio
buffers have leaked, e.g.:
  device-mapper: bufio: leaked buffer 3, hold count 1, list 0

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
6 years agoipmi: move timer init to before irq is setup
Jan Stancek [Tue, 8 Dec 2015 18:57:51 +0000 (13:57 -0500)]
ipmi: move timer init to before irq is setup

commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
        /* Try to claim any interrupts. */
        if (new_smi->irq_setup)

 --> IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer->function) in __mod_timer().

 Call Trace:
   [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
   [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
   [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
   [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
   [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
   [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
   [<ffffffff8100fc59>] handle_irq+0x49/0xa0
   [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
   [<ffffffff8100ba53>] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Corey Minyard <>
Signed-off-by: Jan Stancek <>
Signed-off-by: Tony Camuso <>
Signed-off-by: Corey Minyard <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years ago9p: ->evict_inode() should kick out ->i_data, not ->i_mapping
Al Viro [Tue, 8 Dec 2015 08:07:22 +0000 (03:07 -0500)]
9p: ->evict_inode() should kick out ->i_data, not ->i_mapping

commit 4ad78628445d26e5e9487b2e8f23274ad7b0f5d3 upstream.

For block devices the pagecache is associated with the inode
on bdevfs, not with the aliasing ones on the mountable filesystems.
The latter have its own ->i_data empty and ->i_mapping pointing
to the (unique per major/minor) bdevfs inode.  That guarantees
cache coherence between all block device inodes with the same
device number.

Eviction of an alias inode has no business trying to evict the
pages belonging to bdevfs one; moreover, ->i_mapping is only
safe to access when the thing is opened.  At the time of
->evict_inode() the victim is definitely *not* opened.  We are
about to kill the address space embedded into struct inode
(inode->i_data) and that's what we need to empty of any pages.

9p instance tries to empty inode->i_mapping instead, which is
both unsafe and bogus - if we have several device nodes with
the same device number in different places, closing one of them
should not try to empty the (shared) page cache.

Fortunately, other instances in the tree are OK; they are
evicting from &inode->i_data instead, as 9p one should.

Reported-by: "Suzuki K. Poulose" <>
Tested-by: "Suzuki K. Poulose" <>
Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: rme96: Fix unexpected volume reset after rate changes
Takashi Iwai [Fri, 4 Dec 2015 15:44:24 +0000 (16:44 +0100)]
ALSA: rme96: Fix unexpected volume reset after rate changes

commit a74a821624c0c75388a193337babd17a8c02c740 upstream.

rme96 driver needs to reset DAC depending on the sample rate, and this
results in resetting to the max volume suddenly.  It's because of the
missing call of snd_rme96_apply_dac_volume().

However, calling this function right after the DAC reset still may not
work, and we need some delay before this call.  Since the DAC reset
and the procedure after that are performed in the spinlock, we delay
the DAC volume restore at the end after the spinlock.

Reported-and-tested-by: Sylvain LABOISNE <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agousb: xhci: fix config fail of FS hub behind a HS hub with MTT
Chunfeng Yun [Fri, 4 Dec 2015 13:53:43 +0000 (15:53 +0200)]
usb: xhci: fix config fail of FS hub behind a HS hub with MTT

commit 096b110a3dd3c868e4610937c80d2e3f3357c1a9 upstream.

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agosched/core: Clear the root_domain cpumasks in init_rootdomain()
Xunlei Pang [Wed, 2 Dec 2015 11:52:59 +0000 (19:52 +0800)]
sched/core: Clear the root_domain cpumasks in init_rootdomain()

commit 8295c69925ad53ec32ca54ac9fc194ff21bc40e2 upstream.

root_domain::rto_mask allocated through alloc_cpumask_var()
contains garbage data, this may cause problems. For instance,
When doing pull_rt_task(), it may do useless iterations if
rto_mask retains some extra garbage bits. Worse still, this
violates the isolated domain rule for clustered scheduling
using cpuset, because the tasks(with all the cpus allowed)
belongs to one root domain can be pulled away into another
root domain.

The patch cleans the garbage by using zalloc_cpumask_var()
instead of alloc_cpumask_var() for root_domain::rto_mask
allocation, thereby addressing the issues.

Do the same thing for root_domain's other cpumask memembers:
dlo_mask, span, and online.

Signed-off-by: Xunlei Pang <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Linus Torvalds <>
Cc: Mike Galbraith <>
Cc: Peter Zijlstra <>
Cc: Steven Rostedt <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - There's no dlo_mask to initialise
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agosched/core: Remove false-positive warning from wake_up_process()
Sasha Levin [Tue, 1 Dec 2015 01:34:20 +0000 (20:34 -0500)]
sched/core: Remove false-positive warning from wake_up_process()

commit 119d6f6a3be8b424b200dcee56e74484d5445f7e upstream.

Because wakeups can (fundamentally) be late, a task might not be in
the expected state. Therefore testing against a task's state is racy,
and can yield false positives.

Signed-off-by: Sasha Levin <>
Signed-off-by: Peter Zijlstra (Intel) <>
Acked-by: Linus Torvalds <>
Cc: Mike Galbraith <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Fixes: 9067ac85d533 ("wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agodrm: Fix an unwanted master inheritance v2
Thomas Hellstrom [Wed, 2 Dec 2015 17:24:46 +0000 (09:24 -0800)]
drm: Fix an unwanted master inheritance v2

commit a0af2e538c80f3e47f1d6ddf120a153ad909e8ad upstream.

A client calling drmSetMaster() using a file descriptor that was opened
when another client was master would inherit the latter client's master
object and all its authenticated clients.

This is unwanted behaviour, and when this happens, instead allocate a
brand new master object for the client calling drmSetMaster().

Fixes a BUG() throw in vmw_master_set().

Signed-off-by: Thomas Hellstrom <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2:
 - s/master_mutex/struct_mutex/
 - drm_new_set_master() must drop struct_mutex while calling
 - Adjust filename, context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agolocking: Add WARN_ON_ONCE lock assertion
Peter Hurley [Wed, 10 Sep 2014 18:31:39 +0000 (14:31 -0400)]
locking: Add WARN_ON_ONCE lock assertion

commit 9a37110d20c95d1ebf6c04881177fe8f62831db2 upstream.

An interface may need to assert a lock invariant and not flood the
system logs; add a lockdep helper macro equivalent to
lockdep_assert_held() which only WARNs once.

Signed-off-by: Peter Hurley <>
Acked-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoipv4: igmp: Allow removing groups from a removed interface
Andrew Lunn [Tue, 1 Dec 2015 15:31:08 +0000 (16:31 +0100)]
ipv4: igmp: Allow removing groups from a removed interface

commit 4eba7bb1d72d9bde67d810d09bf62dc207b63c5c upstream.

When a multicast group is joined on a socket, a struct ip_mc_socklist
is appended to the sockets mc_list containing information about the
joined group.

If the interface is hot unplugged, this entry becomes stale. Prior to
commit 52ad353a5344f ("igmp: fix the problem when mc leave group") it
was possible to remove the stale entry by performing a
IP_DROP_MEMBERSHIP, passing either the old ifindex or ip address on
the interface. However, this fix enforces that the interface must
still exist. Thus with time, the number of stale entries grows, until
sysctl_igmp_max_memberships is reached and then it is not possible to
join and more groups.

The previous patch fixes an issue where a IP_DROP_MEMBERSHIP is
performed without specifying the interface, either by ifindex or ip
address. However here we do supply one of these. So loosen the
restriction on device existence to only apply when the interface has
not been specified. This then restores the ability to clean up the
stale entries.

Signed-off-by: Andrew Lunn <>
Fixes: 52ad353a5344f "(igmp: fix the problem when mc leave group")
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodm btree: fix leak of bufio-backed block in btree_split_sibling error path
Mike Snitzer [Mon, 23 Nov 2015 21:24:45 +0000 (16:24 -0500)]
dm btree: fix leak of bufio-backed block in btree_split_sibling error path

commit 30ce6e1cc5a0f781d60227e9096c86e188d2c2bd upstream.

The block allocated at the start of btree_split_sibling() is never
released if later insert_at() fails.

Fix this by releasing the previously allocated bufio block using

Reported-by: Mikulas Patocka <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
6 years agousb: Use the USB_SS_MULT() macro to decode burst multiplier for log message
Ben Hutchings [Wed, 18 Nov 2015 02:01:21 +0000 (02:01 +0000)]
usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message

commit 5377adb092664d336ac212499961cac5e8728794 upstream.

usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.

Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
6 years agoUSB: whci-hcd: add check for dma mapping error
Alexey Khoroshilov [Fri, 20 Nov 2015 21:36:44 +0000 (00:36 +0300)]
USB: whci-hcd: add check for dma mapping error

commit f9fa1887dcf26bd346665a6ae3d3f53dec54cba1 upstream.

qset_fill_page_list() do not check for dma mapping errors.

Found by Linux Driver Verification project (

Signed-off-by: Alexey Khoroshilov <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agowan/x25: Fix use-after-free in x25_asy_open_tty()
Peter Hurley [Fri, 27 Nov 2015 19:18:39 +0000 (14:18 -0500)]
wan/x25: Fix use-after-free in x25_asy_open_tty()

commit ee9159ddce14bc1dec9435ae4e3bd3153e783706 upstream.

The N_X25 line discipline may access the previous line discipline's closed
and already-freed private data on open [1].

The tty->disc_data field _never_ refers to valid data on entry to the
line discipline's open() method. Rather, the ldisc is expected to
initialize that field for its own use for the lifetime of the instance
(ie. from open() to close() only).

    [  634.336761] ==================================================================
    [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
    [  634.339558] Read of size 4 by task syzkaller_execu/8981
    [  634.340359] =============================================================================
    [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
    [  634.405018] Call Trace:
    [  634.405277] dump_stack (lib/dump_stack.c:52)
    [  634.405775] print_trailer (mm/slub.c:655)
    [  634.406361] object_err (mm/slub.c:662)
    [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
    [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
    [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
    [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
    [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
    [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
    [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
    [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
    [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)

Reported-and-tested-by: Sasha Levin <>
Signed-off-by: Peter Hurley <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosata_sil: disable trim
Mikulas Patocka [Thu, 26 Nov 2015 17:00:59 +0000 (12:00 -0500)]
sata_sil: disable trim

commit d98f1cd0a3b70ea91f1dfda3ac36c3b2e1a4d5e2 upstream.

When I connect an Intel SSD to SATA SIL controller (PCI ID 1095:3114), any
TRIM command results in I/O errors being reported in the log. There is
other similar error reported with TRIM and the SIL controller:

Apparently the controller doesn't support TRIM commands. This patch
disables TRIM support on the SATA SIL controller.

ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata7.00: BMDMA2 stat 0x50001
ata7.00: failed command: DATA SET MANAGEMENT
ata7.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 out
         res 51/04:01:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
ata7.00: status: { DRDY ERR }
ata7.00: error: { ABRT }
ata7.00: device reported invalid CHS sector 0
sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 8:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current] [descriptor]
sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unaligned write command
sd 8:0:0:0: [sdb] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 21 95 88 00 20 00 00 00 00
blk_update_request: I/O error, dev sdb, sector 2200968

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agoAHCI: Fix softreset failed issue of Port Multiplier
Xiangliang Yu [Thu, 26 Nov 2015 12:27:02 +0000 (20:27 +0800)]
AHCI: Fix softreset failed issue of Port Multiplier

commit 023113d24ef9e1d2b44cb2446872b17e2b01d8b1 upstream.

Current code doesn't update port value of Port Multiplier(PM) when
sending FIS of softreset to device, command will fail if FBS is

There are two ways to fix the issue: the first is to disable FBS
before sending softreset command to PM device and the second is
to update port value of PM when sending command.

For the first way, i can't find any related rule in AHCI Spec. The
second way can avoid disabling FBS and has better performance.

Signed-off-by: Xiangliang Yu <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/ttm: Fixed a read/write lock imbalance
Thomas Hellstrom [Fri, 20 Nov 2015 19:43:50 +0000 (11:43 -0800)]
drm/ttm: Fixed a read/write lock imbalance

commit 025af189fb44250206dd8a32fa4a682392af3301 upstream.

In ttm_write_lock(), the uninterruptible path should call
__ttm_write_lock() not __ttm_read_lock().  This fixes a vmwgfx hang
on F23 start up.

syeh: Extracted this from one of Thomas' internal patches.

Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Sinclair Yeh <>
Signed-off-by: Ben Hutchings <>
6 years agonfs: if we have no valid attrs, then don't declare the attribute cache valid
Jeff Layton [Wed, 25 Nov 2015 18:50:11 +0000 (13:50 -0500)]
nfs: if we have no valid attrs, then don't declare the attribute cache valid

commit c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 upstream.

If we pass in an empty nfs_fattr struct to nfs_update_inode, it will
(correctly) not update any of the attributes, but it then clears the
NFS_INO_INVALID_ATTR flag, which indicates that the attributes are
up to date. Don't clear the flag if the fattr struct has no valid
attrs to apply.

Reviewed-by: Steve French <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
6 years agoRDS: fix race condition when sending a message on unbound socket
Quentin Casasnovas [Tue, 24 Nov 2015 22:13:21 +0000 (17:13 -0500)]
RDS: fix race condition when sending a message on unbound socket

commit 8c7188b23474cca017b3ef354c4a58456f68303a upstream.

Sasha's found a NULL pointer dereference in the RDS connection code when
sending a message to an apparently unbound socket.  The problem is caused
by the code checking if the socket is bound in rds_sendmsg(), which checks
the rs_bound_addr field without taking a lock on the socket.  This opens a
race where rs_bound_addr is temporarily set but where the transport is not
in rds_bind(), leading to a NULL pointer dereference when trying to
dereference 'trans' in __rds_conn_create().

Vegard wrote a reproducer for this issue, so kindly ask him to share if
you're interested.

I cannot reproduce the NULL pointer dereference using Vegard's reproducer
with this patch, whereas I could without.

Complete earlier incomplete fix to CVE-2015-6937:

  74e98eb08588 ("RDS: verify the underlying transport exists before creating a connection")

Cc: David S. Miller <>
Reviewed-by: Vegard Nossum <>
Reviewed-by: Sasha Levin <>
Acked-by: Santosh Shilimkar <>
Signed-off-by: Quentin Casasnovas <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agojbd2: Fix unreclaimed pages after truncate in data=journal mode
Jan Kara [Tue, 24 Nov 2015 20:34:35 +0000 (15:34 -0500)]
jbd2: Fix unreclaimed pages after truncate in data=journal mode

commit bc23f0c8d7ccd8d924c4e70ce311288cb3e61ea8 upstream.

Ted and Namjae have reported that truncated pages don't get timely
reclaimed after being truncated in data=journal mode. The following test
triggers the issue easily:

for (i = 0; i < 1000; i++) {
pwrite(fd, buf, 1024*1024, 0);
ftruncate(fd, 0);

The reason is that journal_unmap_buffer() finds that truncated buffers
are not journalled (jh->b_transaction == NULL), they are part of
checkpoint list of a transaction (jh->b_cp_transaction != NULL) and have
been already written out (!buffer_dirty(bh)). We clean such buffers but
we leave them in the checkpoint list. Since checkpoint transaction holds
a reference to the journal head, these buffers cannot be released until
the checkpoint transaction is cleaned up. And at that point we don't
call release_buffer_page() anymore so pages detached from mapping are
lingering in the system waiting for reclaim to find them and free them.

Fix the problem by removing buffers from transaction checkpoint lists
when journal_unmap_buffer() finds out they don't have to be there

Reported-and-tested-by: Namjae Jeon <>
Fixes: de1b794130b130e77ffa975bb58cb843744f9ae5
Signed-off-by: Jan Kara <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: Fix handling of extended tv_sec
David Turner [Tue, 24 Nov 2015 19:34:37 +0000 (14:34 -0500)]
ext4: Fix handling of extended tv_sec

commit a4dad1ae24f850410c4e60f22823cba1289b8d52 upstream.

In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
the {a,c,m}time fields, deferring the year 2038 problem to the year

When decoding these extended fields, for times whose bottom 32 bits
would represent a negative number, sign extension causes the 64-bit
extended timestamp to be negative as well, which is not what's
intended.  This patch corrects that issue, so that the only negative
{a,c,m}times are those between 1901 and 1970 (as per 32-bit signed

Some older kernels might have written pre-1970 dates with 1,1 in the
extra bits.  This patch treats those incorrectly-encoded dates as
pre-1970, instead of post-2311, until kernel 4.20 is released.
Hopefully by then e2fsck will have fixed up the bad data.

Also add a comment explaining the encoding of ext4's extra {a,c,m}time

Signed-off-by: David Turner <>
Signed-off-by: Theodore Ts'o <>
Reported-by: Mark Harris <>
Signed-off-by: Ben Hutchings <>
6 years agoring-buffer: Update read stamp with first real commit on page
Steven Rostedt (Red Hat) [Mon, 23 Nov 2015 15:35:36 +0000 (10:35 -0500)]
ring-buffer: Update read stamp with first real commit on page

commit b81f472a208d3e2b4392faa6d17037a89442f4ce upstream.

Do not update the read stamp after swapping out the reader page from the
write buffer. If the reader page is swapped out of the buffer before an
event is written to it, then the read_stamp may get an out of date
timestamp, as the page timestamp is updated on the first commit to that

rb_get_reader_page() only returns a page if it has an event on it, otherwise
it will return NULL. At that point, check if the page being returned has
events and has not been read yet. Then at that point update the read_stamp
to match the time stamp of the reader page.

Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agobroadcom: fix PHY_ID_BCM5481 entry in the id table
Aaro Koskinen [Sat, 21 Nov 2015 23:08:54 +0000 (01:08 +0200)]
broadcom: fix PHY_ID_BCM5481 entry in the id table

commit 3c25a860d17b7378822f35d8c9141db9507e3beb upstream.

Commit fcb26ec5b18d ("broadcom: move all PHY_ID's to header")
updated broadcom_tbl to use PHY_IDs, but incorrectly replaced 0x0143bca0
with PHY_ID_BCM5482 (making a duplicate entry, and completely omitting
the original). Fix that.

Fixes: fcb26ec5b18d ("broadcom: move all PHY_ID's to header")
Signed-off-by: Aaro Koskinen <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agovfs: Avoid softlockups with sendfile(2)
Jan Kara [Mon, 23 Nov 2015 12:09:51 +0000 (13:09 +0100)]
vfs: Avoid softlockups with sendfile(2)

commit c2489e07c0a71a56fb2c84bc0ee66cddfca7d068 upstream.

The following test program from Dmitry can cause softlockups or RCU
stalls as it copies 1GB from tmpfs into eventfd and we don't have any
scheduling point at that path in sendfile(2) implementation:

        int r1 = eventfd(0, 0);
        int r2 = memfd_create("", 0);
        unsigned long n = 1<<30;
        fallocate(r2, 0, 0, n);
        sendfile(r1, r2, 0, n);

Add cond_resched() into __splice_from_pipe() to fix the problem.

CC: Dmitry Vyukov <>
Signed-off-by: Jan Kara <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agovfs: Make sendfile(2) killable even better
Jan Kara [Mon, 23 Nov 2015 12:09:50 +0000 (13:09 +0100)]
vfs: Make sendfile(2) killable even better

commit c725bfce7968009756ed2836a8cd7ba4dc163011 upstream.

Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny writes into a filesystem and thus
was unkillable for a long time. However sendfile(2) can be (mis)used to
issue lots of writes into arbitrary file descriptor such as evenfd or
similar special file descriptors which never hit the standard filesystem
write path and thus are still unkillable. E.g. the following example
from Dmitry burns CPU for ~16s on my test system without possibility to
be killed:

        int r1 = eventfd(0, 0);
        int r2 = memfd_create("", 0);
        unsigned long n = 1<<30;
        fallocate(r2, 0, 0, n);
        sendfile(r1, r2, 0, n);

There are actually quite a few tests for pending signals in sendfile
code however we data to write is always available none of them seems to
trigger. So fix the problem by adding a test for pending signal into
splice_from_pipe_next() also before the loop waiting for pipe buffers to
be available. This should fix all the lockup issues with sendfile of the
do-ton-of-tiny-writes nature.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Jan Kara <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agofix sysvfs symlinks
Al Viro [Tue, 24 Nov 2015 02:11:08 +0000 (21:11 -0500)]
fix sysvfs symlinks

commit 0ebf7f10d67a70e120f365018f1c5fce9ddc567d upstream.

The thing got broken back in 2002 - sysvfs does *not* have inline
symlinks; even short ones have bodies stored in the first block
of file.  sysv_symlink() handles that correctly; unfortunately,
attempting to look an existing symlink up will end up confusing
them for inline symlinks, and interpret the block number containing
the body as the body itself.

Nobody has noticed until now, which says something about the level
of testing sysvfs gets ;-/

Signed-off-by: Al Viro <>
[bwh: Backported to 3.2:
 - Adjust context
 - Also delete unused sysv_fast_symlink_inode_operations]
Signed-off-by: Ben Hutchings <>
6 years agounix: avoid use-after-free in ep_remove_wait_queue
Rainer Weikusat [Fri, 20 Nov 2015 22:07:23 +0000 (22:07 +0000)]
unix: avoid use-after-free in ep_remove_wait_queue

commit 7d267278a9ece963d77eefec61630223fce08c6c upstream.

Rainer Weikusat <> writes:
An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams. This implies that prospective writers might be forced to go
to sleep despite none of the message presently enqueued on the server
receive queue were sent by them. In order to ensure that these will be
woken up once space becomes again available, the present unix_dgram_poll
routine does a second sock_poll_wait call with the peer_wait wait queue
of the server socket as queue argument (unix_dgram_recvmsg does a wake
up on this queue after a datagram was received). This is inherently
problematic because the server socket is only guaranteed to remain alive
for as long as the client still holds a reference to it. In case the
connection is dissolved via connect or by the dead peer detection logic
in unix_dgram_sendmsg, the server socket may be freed despite "the
polling mechanism" (in particular, epoll) still has a pointer to the
corresponding peer_wait queue. There's no way to forcibly deregister a
wait queue with epoll.

Based on an idea by Jason Baron, the patch below changes the code such
that a wait_queue_t belonging to the client socket is enqueued on the
peer_wait queue of the server whenever the peer receive queue full
condition is detected by either a sendmsg or a poll. A wake up on the
peer queue is then relayed to the ordinary wait queue of the client
socket via wake function. The connection to the peer wait queue is again
dissolved if either a wake up is about to be relayed or the client
socket reconnects or a dead peer is detected or the client socket is
itself closed. This enables removing the second sock_poll_wait from
unix_dgram_poll, thus avoiding the use-after-free, while still ensuring
that no blocked writer sleeps forever.

Signed-off-by: Rainer Weikusat <>
Fixes: ec0d215f9420 ("af_unix: fix 'poll for write'/connected DGRAM sockets")
Reviewed-by: Jason Baron <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: cdc_acm: Ignore Infineon Flash Loader utility
Jonas Jonsson [Sun, 22 Nov 2015 10:47:17 +0000 (11:47 +0100)]
USB: cdc_acm: Ignore Infineon Flash Loader utility

commit f33a7f72e5fc033daccbb8d4753d7c5c41a4d67b upstream.

Some modems, such as the Telit UE910, are using an Infineon Flash Loader
utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
Data). The latter can be used as a serial interface to upgrade the
firmware of the modem. However, that isn't possible when the cdc-acm
driver takes control of the device.

The following is an explanation of the behaviour by Daniele Palmas during
discussion on linux-usb.

"This is what happens when the device is turned on (without modifying
the drivers):

[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

This is the flashing device that is caught by the cdc-acm driver. Once
the ttyACM appears, the application starts sending a magic string
(simple write on the file descriptor) to keep the device in flashing
mode. If this magic string is not properly received in a certain time
interval, the modem goes on in normal operative mode:

[155493.748094] usb 1-3: USB disconnect, device number 27
[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
[155495.059989] usb 1-3: Manufacturer: Telit
[155495.059992] usb 1-3: SerialNumber: 359658044004697
[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at usb-0000:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14

Using the cdc-acm driver, the string, though being sent in the same way
than using the usb-serial-simple driver (I can confirm that the data is
passing properly since I used an hw usb sniffer), does not make the
device to stay in flashing mode."

Signed-off-by: Jonas Jonsson <>
Tested-by: Daniele Palmas <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: cdc-acm - Add IGNORE_DEVICE quirk
Ben Hutchings [Wed, 23 Dec 2015 17:51:35 +0000 (17:51 +0000)]
USB: cdc-acm - Add IGNORE_DEVICE quirk

Extracted from commit 16142655269a ("USB: cdc-acm - blacklist IMS PCU

Signed-off-by: Ben Hutchings <>
6 years agoUSB: cp210x: Remove CP2110 ID from compatibility list
Konstantin Shkolnyy [Tue, 10 Nov 2015 22:40:13 +0000 (16:40 -0600)]
USB: cp210x: Remove CP2110 ID from compatibility list

commit 7c90e610b60cd1ed6abafd806acfaedccbbe52d1 upstream.

CP2110 ID (0x10c4, 0xea80) doesn't belong here because it's a HID
and completely different from CP210x devices.

Signed-off-by: Konstantin Shkolnyy <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agocan: sja1000: clear interrupts on start
Mirza Krak [Tue, 10 Nov 2015 13:59:34 +0000 (14:59 +0100)]
can: sja1000: clear interrupts on start

commit 7cecd9ab80f43972c056dc068338f7bcc407b71c upstream.

According to SJA1000 data sheet error-warning (EI) interrupt is not
cleared by setting the controller in to reset-mode.

Then if we have the following case:
- system is suspended (echo mem > /sys/power/state) and SJA1000 is left
  in operating state
- A bus error condition occurs which activates EI interrupt, system is
  still suspended which means EI interrupt will be not be handled nor

If the above two events occur, on resume there is no way to return the
SJA1000 to operating state, except to cycle power to it.

By simply reading the IR register on start we will clear any previous
conditions that could be present.

Signed-off-by: Mirza Krak <>
Reported-by: Christian Magnusson <>
Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: s/SJA1000_IR/REG_IR/]
Signed-off-by: Ben Hutchings <>
6 years agonet: ip6mr: fix static mfc/dev leaks on table destruction
Nikolay Aleksandrov [Fri, 20 Nov 2015 12:54:20 +0000 (13:54 +0100)]
net: ip6mr: fix static mfc/dev leaks on table destruction

commit 4c6980462f32b4f282c5d8e5f7ea8070e2937725 upstream.

Similar to ipv4, when destroying an mrt table the static mfc entries and
the static devices are kept, which leads to devices that can never be
destroyed (because of refcnt taken) and leaked memory. Make sure that
everything is cleaned up on netns destruction.

Fixes: 8229efdaef1e ("netns: ip6mr: enable namespace support in ipv6 multicast forwarding code")
CC: Benjamin Thery <>
Signed-off-by: Nikolay Aleksandrov <>
Reviewed-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoip6mr: call del_timer_sync() in ip6mr_free_table()
WANG Cong [Tue, 31 Mar 2015 18:01:47 +0000 (11:01 -0700)]
ip6mr: call del_timer_sync() in ip6mr_free_table()

commit 7ba0c47c34a1ea5bc7a24ca67309996cce0569b5 upstream.

We need to wait for the flying timers, since we
are going to free the mrtable right after it.

Cc: Hannes Frederic Sowa <>
Signed-off-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agomac: validate mac_partition is within sector
Kees Cook [Fri, 20 Nov 2015 01:18:54 +0000 (17:18 -0800)]
mac: validate mac_partition is within sector

commit 02e2a5bfebe99edcf9d694575a75032d53fe1b73 upstream.

If md->signature == MAC_DRIVER_MAGIC and md->block_size == 1023, a single
512 byte sector would be read (secsize / 512). However the partition
structure would be located past the end of the buffer (secsize % 512).

Signed-off-by: Kees Cook <>
Signed-off-by: Jens Axboe <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agousblp: do not set TASK_INTERRUPTIBLE before lock
Jiri Slaby [Mon, 2 Nov 2015 09:27:00 +0000 (10:27 +0100)]
usblp: do not set TASK_INTERRUPTIBLE before lock

commit 19cd80a214821f4b558560ebd76bfb2c38b4f3d8 upstream.

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffa0c588d0>] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: G        W       4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81a4edce ffff880236ec7ba8 ffffffff81716651 0000000000000000
 ffff880236ec7bf8 ffff880236ec7be8 ffffffff8106e146 0000000000000282
 ffffffff81a50119 000000000000028b 0000000000000000 ffff8802dab7c508
Call Trace:
 [<ffffffff8106e1c6>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff8109a8bd>] __might_sleep+0x7d/0x90
 [<ffffffff8171b20f>] mutex_lock_interruptible_nested+0x2f/0x4b0
 [<ffffffffa0c588fc>] usblp_wwait+0xcc/0x310 [usblp]
 [<ffffffffa0c58bb2>] usblp_write+0x72/0x350 [usblp]
 [<ffffffff8121ed98>] __vfs_write+0x28/0xf0

Commit 7f477358e2384c54b190cc3b6ce28277050a041b (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.

Signed-off-by: Jiri Slaby <>
Fixes: 7f477358e2 ("usblp: Implement the ENOSPC convention")
Acked-By: Pete Zaitcev <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: option: add XS Stick W100-2 from 4G Systems
Bjørn Mork [Wed, 18 Nov 2015 20:12:33 +0000 (21:12 +0100)]
USB: option: add XS Stick W100-2 from 4G Systems

commit 638148e20c7f8f6e95017fdc13bce8549a6925e0 upstream.

Thomas reports
4gsystems sells two total different LTE-surfsticks under the same name.
The newer version of XS Stick W100 is from "omega"
Under windows the driver switches to the same ID, and uses MI03\6 for
network and MI01\6 for modem.
echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9b01 Rev=02.32
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Now all important things are there:

wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)

There is also ttyUSB0, but it is not usable, at least not for at.

The device works well with qmi and ModemManager-NetworkManager.

Reported-by: Thomas Schäfer <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Workaround to get Intel xHCI reset working more reliably
Rajmohan Mani [Wed, 18 Nov 2015 08:48:20 +0000 (10:48 +0200)]
xhci: Workaround to get Intel xHCI reset working more reliably

commit a5964396190d0c40dd549c23848c282fffa5d1f2 upstream.

Existing Intel xHCI controllers require a delay of 1 mS,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.

Verified CherryView / Braswell platforms go through over
5000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang.

Signed-off-by: Rajmohan Mani <>
Tested-by: Joe Lawrence <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Add XHCI_INTEL_HOST quirk
Ben Hutchings [Wed, 23 Dec 2015 13:57:50 +0000 (13:57 +0000)]
xhci: Add XHCI_INTEL_HOST quirk

Extracted from commit e3567d2c15a7 ("xhci: Add Intel U1/U2 timeout policy.")

Signed-off-by: Ben Hutchings <>
6 years agomacvlan: fix leak in macvlan_handle_frame
Sabrina Dubroca [Mon, 16 Nov 2015 21:54:20 +0000 (22:54 +0100)]
macvlan: fix leak in macvlan_handle_frame

commit e639b8d8a7a728f0b05ef2df6cb6b45dc3d4e556 upstream.

Reset pskb in macvlan_handle_frame in case skb_share_check returned a

Fixes: 8a4eb5734e8d ("net: introduce rx_handler results and logic around that")
Signed-off-by: Sabrina Dubroca <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agomac80211: mesh: fix call_rcu() usage
Johannes Berg [Tue, 17 Nov 2015 13:25:21 +0000 (14:25 +0100)]
mac80211: mesh: fix call_rcu() usage

commit c2e703a55245bfff3db53b1f7cbe59f1ee8a4339 upstream.

When using call_rcu(), the called function may be delayed quite
significantly, and without a matching rcu_barrier() there's no
way to be sure it has finished.
Therefore, global state that could be gone/freed/reused should
never be touched in the callback.

Fix this in mesh by moving the atomic_dec() into the caller;
that's not really a problem since we already unlinked the path
and it will be destroyed anyway.

This fixes a crash Jouni observed when running certain tests in
a certain order, in which the mesh interface was torn down, the
memory reused for a function pointer (work struct) and running
that then crashed since the pointer had been decremented by 1,
resulting in an invalid instruction byte stream.

Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
Reported-by: Jouni Malinen <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
6 years agoFS-Cache: Add missing initialization of ret in cachefiles_write_page()
Geert Uytterhoeven [Thu, 12 Nov 2015 11:46:23 +0000 (11:46 +0000)]
FS-Cache: Add missing initialization of ret in cachefiles_write_page()

commit cf89752645e47d86ba8a4157f4b121fcb33434c5 upstream.

fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function

If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.

Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: David Howells <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agonet: fix __netdev_update_features return on ndo_set_features failure
Nikolay Aleksandrov [Fri, 13 Nov 2015 14:20:24 +0000 (15:20 +0100)]
net: fix __netdev_update_features return on ndo_set_features failure

commit 00ee5927177792a6e139d50b6b7564d35705556a upstream.

If ndo_set_features fails __netdev_update_features() will return -1 but
this is wrong because it is expected to return 0 if no features were
changed (see netdev_update_features()), which will cause a netdev
notifier to be called without any actual changes. Fix this by returning
0 if ndo_set_features fails.

Fixes: 6cb6a27c45ce ("net: Call netdev_features_change() from netdev_update_features()")
CC: Michał Mirosław <>
Signed-off-by: Nikolay Aleksandrov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8962: correct addresses for HPF_C_0/1
Sachin Pandhare [Tue, 10 Nov 2015 18:08:02 +0000 (23:38 +0530)]
ASoC: wm8962: correct addresses for HPF_C_0/1

commit e9f96bc53c1b959859599cb30ce6fd4fbb4448c2 upstream.

From datasheet:
R17408 (4400h) HPF_C_1
R17409 (4401h) HPF_C_0
17048 -> 17408 (0x4400)
17049 -> 17409 (0x4401)

Signed-off-by: Sachin Pandhare <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
[bwh: Backported to 3.2: wm8962_reg is a sparse array, not an array of
 { offset, value } pairs]
Signed-off-by: Ben Hutchings <>