commit d9d351829536cc2cf6331c83e7859f5cb495e0c5
Author: Jiri Slaby <jslaby@suse.cz>
Date: Wed Mar 16 09:29:22 2016 +0100
Linux 3.12.57
commit 372e06155eb9a01cdff0b87c6ac4347448a5273c
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Feb 11 16:10:23 2016 -0500
xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY
commit 8d47065f7d1980dde52abb874b301054f3013602 upstream.
Commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't
allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
MSI-X on passed-through virtual functions, because it checked the VF
for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.
Instead, check the physical function for PCI_COMMAND_MEMORY.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit bb7aa305af0fd136dde25ad65ec0d3279d809d8b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon Nov 2 18:13:27 2015 -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 <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 388a80050ecc11ef32cce451426c436aa6cf69ac
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed Apr 1 10:49:47 2015 -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 <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 4113b288a5eab3b7b0dcf66922eb1e34ff2a16f2
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon Nov 2 17:24:08 2015 -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
'xen_pcibk_control_isr'.
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.
P.S.
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 <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit d8e0a80d370c6608fb96cd371948ccd6497153f1
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon Nov 2 18:07:44 2015 -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 <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 0842f7d8a78ff7f9c3a176abaa620a220fc82e75
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri Apr 3 11:08:22 2015 -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:
BUG_ON(list_empty(dev_to_msi_list(&dev->dev)));
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 <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit a801fe8935d78c2d900b0d8a422ee3bef2ea7bf2
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed Feb 3 16:55:26 2016 +1030
modules: fix longstanding /proc/kallsyms vs module insertion race.
commit 8244062ef1e54502ef55f54cced659913f244c3e upstream.
For CONFIG_KALLSYMS, we keep two symbol tables and two string tables.
There's one full copy, marked SHF_ALLOC and laid out at the end of the
module's init section. There's also a cut-down version that only
contains core symbols and strings, and lives in the module's core
section.
After module init (and before we free the module memory), we switch
the mod->symtab, mod->num_symtab and mod->strtab to point to the core
versions. We do this under the module_mutex.
However, kallsyms doesn't take the module_mutex: it uses
preempt_disable() and rcu tricks to walk through the modules, because
it's used in the oops path. It's also used in /proc/kallsyms.
There's nothing atomic about the change of these variables, so we can
get the old (larger!) num_symtab and the new symtab pointer; in fact
this is what I saw when trying to reproduce.
By grouping these variables together, we can use a
carefully-dereferenced pointer to ensure we always get one or the
other (the free of the module init section is already done in an RCU
callback, so that's safe). We allocate the init one at the end of the
module init section, and keep the core one inside the struct module
itself (it could also have been allocated at the end of the module
core, but that's probably overkill).
[ Rebased for 4.4-stable and older, because the following changes aren't
in the older trees:
- e0224418516b4d8a6c2160574bac18447c354ef0: adds arg to is_core_symbol
- 7523e4dc5057e157212b4741abd6256e03404cf1: module_init/module_core/init_size/core_size
become init_layout.base/core_layout.base/init_layout.size/core_layout.size.
Original commit: 8244062ef1e54502ef55f54cced659913f244c3e
]
Reported-by: Weilong Chen <chenweilong@huawei.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 1f62ed7f71730330bd0085276725ed1a39eb0085
Author: Jason Andryuk <jandryuk@gmail.com>
Date: Fri Feb 12 23:13:33 2016 +0000
lib/ucs2_string: Correct ucs2 -> utf8 conversion
commit a68075908a37850918ad96b056acc9ac4ce1bd90 upstream.
The comparisons should be >= since 0x800 and 0x80 require an additional bit
to store.
For the 3 byte case, the existing shift would drop off 2 more bits than
intended.
For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@coreos.com>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit ba1b60191c4fbf4e3e1192ed2d28511238fbead2
Author: Matt Fleming <matt@codeblueprint.co.uk>
Date: Mon Feb 15 10:34:05 2016 +0000
efi: Add pstore variables to the deletion whitelist
commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 upstream.
Laszlo explains why this is a good idea,
'This is because the pstore filesystem can be backed by UEFI variables,
and (for example) a crash might dump the last kilobytes of the dmesg
into a number of pstore entries, each entry backed by a separate UEFI
variable in the above GUID namespace, and with a variable name
according to the above pattern.
Please see "drivers/firmware/efi/efi-pstore.c".
While this patch series will not prevent the user from deleting those
UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
entry will continue to delete the backing UEFI variable), I think it
would be nice to preserve the possibility for the sysadmin to delete
Linux-created UEFI variables that carry portions of the crash log,
*without* having to mount the pstore filesystem.'
There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.
Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Tested-by: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 9a4e72fd30356aa8d017c1dcc6a29d11a41093b7
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:15 2016 -0500
efi: Make efivarfs entries immutable by default
commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 upstream.
"rm -rf" is bricking some peoples' laptops because of variables being
used to store non-reinitializable firmware driver data that's required
to POST the hardware.
These are 100% bugs, and they need to be fixed, but in the mean time it
shouldn't be easy to *accidentally* brick machines.
We have to have delete working, and picking which variables do and don't
work for deletion is quite intractable, so instead make everything
immutable by default (except for a whitelist), and make tools that
aren't quite so broad-spectrum unset the immutable flag.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit c85622810f3ee366b54661f9580860160fd82c58
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:14 2016 -0500
efi: Make our variable validation list include the guid
commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f upstream.
All the variables in this list so far are defined to be in the global
namespace in the UEFI spec, so this just further ensures we're
validating the variables we think we are.
Including the guid for entries will become more important in future
patches when we decide whether or not to allow deletion of variables
based on presence in this list.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 9b73e95fe04b78c8d507c4e193cfe30bd9f1f1fc
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:13 2016 -0500
efi: Do variable name validation tests in utf8
commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 upstream.
Actually translate from ucs2 to utf8 before doing the test, and then
test against our other utf8 data, instead of fudging it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit bbe4e68df61a0445530f871a54344baf8de7a3c4
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:12 2016 -0500
efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
commit e0d64e6a880e64545ad7d55786aa84ab76bac475 upstream.
Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
all variable names fit in ASCII.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit e9699a08eb89c16351b4da8b34ab59e2caa448ea
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:11 2016 -0500
lib/ucs2_string: Add ucs2 -> utf8 helper functions
commit 73500267c930baadadb0d02284909731baf151f7 upstream.
This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit b7dc78251de7c991a3858ab5a7a56ba604cbb908
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Wed Oct 14 19:33:09 2015 -0300
KVM: x86: move steal time initialization to vcpu entry time
commit 7cae2bedcbd4680b155999655e49c27b9cf020fa upstream.
As reported at https://bugs.launchpad.net/qemu/+bug/1494350,
it is possible to have vcpu->arch.st.last_steal initialized
from a thread other than vcpu thread, say the iothread, via
KVM_SET_MSRS.
Which can cause an overflow later (when subtracting from vcpu threads
sched_info.run_delay).
To avoid that, move steal time accumulation to vcpu entry time,
before copying steal time data to guest.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 63ec4087e92fb510ab047f1115ccd9bdff37e1ef
Author: Andreas Schwab <schwab@linux-m68k.org>
Date: Fri Feb 5 19:50:03 2016 +0100
powerpc: Fix dedotify for binutils >= 2.26
commit f15838e9cac8f78f0cc506529bb9d3b9fa589c1f upstream.
Since binutils 2.26 BFD is doing suffix merging on STRTAB sections. But
dedotify modifies the symbol names in place, which can also modify
unrelated symbols with a name that matches a suffix of a dotted name. To
remove the leading dot of a symbol name we can just increment the pointer
into the STRTAB section instead.
Backport to all stables to avoid breakage when people update their
binutils - mpe.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 5b2e8b9586c2e11f95f5bdd5783259941d17c0f3
Author: Felix Fietkau <nbd@openwrt.org>
Date: Thu Feb 18 19:49:18 2016 +0100
mac80211: minstrel_ht: set default tx aggregation timeout to 0
commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 upstream.
The value 5000 was put here with the addition of the timeout field to
ieee80211_start_tx_ba_session. It was originally added in mac80211 to
save resources for drivers like iwlwifi, which only supports a limited
number of concurrent aggregation sessions.
Since iwlwifi does not use minstrel_ht and other drivers don't need
this, 0 is a better default - especially since there have been
recent reports of aggregation setup related issues reproduced with
ath9k. This should improve stability without causing any adverse
effects.
Acked-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 80e7964b14d9c84ac9ff4edeed5942516c98e125
Author: Johannes Berg <johannes.berg@intel.com>
Date: Wed Jan 27 12:37:52 2016 +0100
wext: fix message delay/ordering
commit 8bf862739a7786ae72409220914df960a0aa80d8 upstream.
Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been connected and disconnection while it was deleted
caused a wext message.
For its netlink messages, wext uses RTM_NEWLINK, but the message is
without all the regular rtnetlink attributes, so "ip monitor link"
prints just rudimentary information:
5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: <BROADCAST,MULTICAST,UP>
link/ether
(from my hwsim reproduction)
This can cause userspace to get confused since it doesn't expect an
RTM_NEWLINK message after RTM_DELLINK.
The reason for this is that wext schedules a worker to send out the
messages, and the scheduling delay can cause the messages to get out
to userspace in different order.
To fix this, have wext register a netdevice notifier and flush out
any pending messages when netdevice state changes. This fixes any
ordering whenever the original message wasn't sent by a notifier
itself.
Reported-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 812b5d209a7c2a71a0b5f2fe9b6ebd4e4590adc9
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 29 18:01:12 2016 +0100
ASoC: wm8958: Fix enum ctl accesses in a wrong type
commit d0784829ae3b0beeb69b476f017d5c8a2eb95198 upstream.
"MBC Mode", "VSS Mode", "VSS HPF Mode" and "Enhanced EQ Mode" ctls in
wm8958 codec driver are enum, while the current driver accesses
wrongly via value.integer.value[]. They have to be via
value.enumerated.item[] instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit c4728f49a512548e9ecb97fe0c6ed65c05f713d2
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 29 18:01:15 2016 +0100
ASoC: wm8994: Fix enum ctl accesses in a wrong type
commit 8019c0b37cd5a87107808300a496388b777225bf upstream.
The DRC Mode like "AIF1DRC1 Mode" and EQ Mode like "AIF1.1 EQ Mode" in
wm8994 codec driver are enum ctls, while the current driver accesses
wrongly via value.integer.value[]. They have to be via
value.enumerated.item[] instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit eb2be84ea08addd6c99a38921d5066d4fd79439c
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date: Wed Mar 9 11:58:41 2016 -0500
tracing: Fix check for cpu online when event is disabled
commit dc17147de328a74bbdee67c1bf37d2f1992de756 upstream.
Commit f37755490fe9b ("tracepoints: Do not trace when cpu is offline") added
a check to make sure that tracepoints only get called when the cpu is
online, as it uses rcu_read_lock_sched() for protection.
Commit 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints
are disabled") added lockdep checks (including rcu checks) for events that
are not enabled to catch possible RCU issues that would only be triggered if
a trace event was enabled. Commit f37755490fe9b only stopped the warnings
when the trace event was enabled but did not prevent warnings if the trace
event was called when disabled.
To fix this, the cpu online check is moved to where the condition is added
to the trace event. This will place the cpu online check in all places that
it may be used now and in the future.
Fixes: f37755490fe9b ("tracepoints: Do not trace when cpu is offline")
Fixes: 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints are disabled")
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6199e8f4a8b9ab205d5c61726915e6f187d5435
Author: Radim KrÄmář <rkrcmar@redhat.com>
Date: Fri Mar 4 15:08:42 2016 +0100
KVM: VMX: disable PEBS before a guest entry
commit 7099e2e1f4d9051f31bbfa5803adf954bb5d76ef upstream.
Linux guests on Haswell (and also SandyBridge and Broadwell, at least)
would crash if you decided to run a host command that uses PEBS, like
perf record -e 'cpu/mem-stores/pp' -a
This happens because KVM is using VMX MSR switching to disable PEBS, but
SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it
isn't safe:
When software needs to reconfigure PEBS facilities, it should allow a
quiescent period between stopping the prior event counting and setting
up a new PEBS event. The quiescent period is to allow any latent
residual PEBS records to complete its capture at their previously
specified buffer address (provided by IA32_DS_AREA).
There might not be a quiescent period after the MSR switch, so a CPU
ends up using host's MSR_IA32_DS_AREA to access an area in guest's
memory. (Or MSR switching is just buggy on some models.)
The guest can learn something about the host this way:
If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results
in #PF where we leak host's MSR_IA32_DS_AREA through CR2.
After that, a malicious guest can map and configure memory where
MSR_IA32_DS_AREA is pointing and can therefore get an output from
host's tracing.
This is not a critical leak as the host must initiate with PEBS tracing
and I have not been able to get a record from more than one instruction
before vmentry in vmx_vcpu_run() (that place has most registers already
overwritten with guest's).
We could disable PEBS just few instructions before vmentry, but
disabling it earlier shouldn't affect host tracing too much.
We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that
optimization isn't worth its code, IMO.
(If you are implementing PEBS for guests, be sure to handle the case
where both host and guest enable PEBS, because this patch doesn't.)
Fixes: 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
Reported-by: Jiřà Olša <jolsa@redhat.com>
Signed-off-by: Radim KrÄmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit a98603c5b956c44a37243d2d01e6c4b024201bba
Author: Jiri Slaby <jslaby@suse.cz>
Date: Mon Mar 14 13:33:30 2016 +0100
Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
This reverts commit 40df18b49e7fe4ec9ab93f68c33661ee291149bd, commit
f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.
It causes oopses:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa010345d>] radeon_fence_ref+0xd/0x50 [radeon]
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: Christian König <christian.koenig@amd.com>
commit 1cfdd759db4f056477b72357df2f95786a52b541
Author: Richard Weinberger <richard@nod.at>
Date: Sun Feb 21 10:53:03 2016 +0100
ubi: Fix out of bounds write in volume update code
commit e4f6daac20332448529b11f09388f1d55ef2084c upstream.
ubi_start_leb_change() allocates too few bytes.
ubi_more_leb_change_data() will write up to req->upd_bytes +
ubi->min_io_size bytes.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit e7d14f3420e856cc38fa64915e08e8ca98297692
Author: Maciej W. Rozycki <macro@imgtec.com>
Date: Fri Mar 4 01:42:49 2016 +0000
MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'
commit e723e3f7f9591b79e8c56b3d7c5a204a9c571b55 upstream.
Avoid sending a partially initialised `siginfo_t' structure along SIGFPE
signals issued from `do_ov' and `do_trap_or_bp', leading to information
leaking from the kernel stack.
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 43b6aad7574191f9f1a9e1f6e36a93ba93f6dbe0
Author: Yegor Yefremov <yegorslists@googlemail.com>
Date: Mon Feb 29 16:39:57 2016 +0100
USB: serial: option: add support for Quectel UC20
commit c0992d0f54847d0d1d85c60fcaa054f175ab1ccd upstream.
Add support for Quectel UC20 and blacklist the QMI interface.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
[johan: amend commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 9e7578444a23c76ec032d7b1056868991b646742
Author: Daniele Palmas <dnlplm@gmail.com>
Date: Mon Feb 29 15:36:11 2016 +0100
USB: serial: option: add support for Telit LE922 PID 0x1045
commit 5deef5551c77e488922cc4bf4bc76df63be650d0 upstream.
This patch adds support for 0x1045 PID of Telit LE922.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 887365e0af1874cd75e9450be1f9d63d8ddde6b0
Author: Vittorio Alfieri <vittorio88@gmail.com>
Date: Sun Feb 28 14:40:24 2016 +0100
USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder
commit 3c4c615d70c8cbdc8ba8c79ed702640930652a79 upstream.
The Parrot NMEA GPS Flight Recorder is a USB composite device
consisting of hub, flash storage, and cp210x usb to serial chip.
It is an accessory to the mass-produced Parrot AR Drone 2.
The device emits standard NMEA messages which make the it compatible
with NMEA compatible software. It was tested using gpsd version 3.11-3
as an NMEA interpreter and using the official Parrot Flight Recorder.
Signed-off-by: Vittorio Alfieri <vittorio88@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit a4804d0e21dfa0aa67d51b2ffb9c3ee9f9acaa16
Author: Takashi Iwai <tiwai@suse.de>
Date: Sun Feb 28 11:36:14 2016 +0100
ALSA: timer: Fix broken compat timer user status ioctl
commit 3a72494ac2a3bd229db941d51e7efe2f6ccd947b upstream.
The timer user status compat ioctl returned the bogus struct used for
64bit architectures instead of the 32bit one. This patch addresses
it to return the proper struct.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit a041d47fcdb1032b09636e4f8183f089999a7e0d
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 29 14:32:42 2016 +0100
ALSA: hdspm: Fix zero-division
commit c1099c3294c2344110085a38c50e478a5992b368 upstream.
HDSPM driver contains a code issuing zero-division potentially in
system sample rate ctl code. This patch fixes it by not processing
a zero or invalid rate value as a divisor, as well as excluding the
invalid value to be passed via the given ctl element.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 6cc1e98de81b68a4e15088ac504ea6677288e9aa
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 29 14:26:43 2016 +0100
ALSA: hdsp: Fix wrong boolean ctl value accesses
commit eab3c4db193f5fcccf70e884de9a922ca2c63d80 upstream.
snd-hdsp driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements. This patch fixes them.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 4e4ac2043c0519274753ef4c3b455946f4bbd2e3
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 29 14:25:16 2016 +0100
ALSA: hdspm: Fix wrong boolean ctl value accesses
commit 537e48136295c5860a92138c5ea3959b9542868b upstream.
snd-hdspm driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements. This patch fixes them.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit ddd16958041ff9797a6a47bb3599ddfe5c4a81da
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Mar 1 18:30:18 2016 +0100
ALSA: seq: oss: Don't drain at closing a client
commit 197b958c1e76a575d77038cc98b4bebc2134279f upstream.
The OSS sequencer client tries to drain the pending events at
releasing. Unfortunately, as spotted by syzkaller fuzzer, this may
lead to an unkillable process state when the event has been queued at
the far future. Since the process being released can't be signaled
any longer, it remains and waits for the echo-back event in that far
future.
Back to history, the draining feature was implemented at the time we
misinterpreted POSIX definition for blocking file operation.
Actually, such a behavior is superfluous at release, and we should
just release the device as is instead of keeping it up forever.
This patch just removes the draining call that may block the release
for too long time unexpectedly.
BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 956093275c51549f7775e8129fbe8f0295efa6c6
Author: Takashi Iwai <tiwai@suse.de>
Date: Sun Feb 28 11:41:47 2016 +0100
ALSA: timer: Fix ioctls for X32 ABI
commit b24e7ad1fdc22177eb3e51584e1cfcb45d818488 upstream.
X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
incompatible with IA32. This results in NOTTY error when the ioctl is
issued.
Meanwhile, this struct in X32 is essentially identical with the one in
X86-64, so we can just bypassing to the existing code for this
specific compat ioctl.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 808ce90e7f1b1a24f881a9aea10b0407568f3f0a
Author: Takashi Iwai <tiwai@suse.de>
Date: Sun Feb 28 11:28:08 2016 +0100
ALSA: rawmidi: Fix ioctls X32 ABI
commit 2251fbbc1539f05b0b206b37a602d5776be37252 upstream.
Like the previous fixes for ctl and PCM, we need a fix for
incompatible X32 ABI regarding the rawmidi: namely, struct
snd_rawmidi_status has the timespec, and the size and the alignment on
X32 differ from IA32.
This patch fixes the incompatible ioctl for X32.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit eb6e5b37207994868f7188b7627fd9751be5a1e4
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Feb 27 17:52:42 2016 +0100
ALSA: ctl: Fix ioctls for X32 ABI
commit 6236d8bb2afcfe71b88ecea554e0dc638090a45f upstream.
The X32 ABI takes the same alignment like x86-64, and this may result
in the incompatible struct size from ia32. Unfortunately, we hit this
in some control ABI: struct snd_ctl_elem_value differs between them
due to the position of 64bit variable array. This ends up with the
unknown ioctl (ENOTTY) error.
The fix is to add the compat entries for the new aligned struct.
Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit b114d10a8707955b444a98f8c78aabfc0f4ccdcd
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Mon Feb 1 14:04:46 2016 +0000
Fix directory hardlinks from deleted directories
commit be629c62a603e5935f8177fd8a19e014100a259e upstream.
When a directory is deleted, we don't take too much care about killing off
all the dirents that belong to it — on the basis that on remount, the scan
will conclude that the directory is dead anyway.
This doesn't work though, when the deleted directory contained a child
directory which was moved *out*. In the early stages of the fs build
we can then end up with an apparent hard link, with the child directory
appearing both in its true location, and as a child of the original
directory which are this stage of the mount process we don't *yet* know
is defunct.
To resolve this, take out the early special-casing of the "directories
shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
normal nlink processing happen for directories as well as other inodes.
Then later in the build process we can set ic->pino_nlink to the parent
inode#, as is required for directories during normal operaton, instead
of the nlink. And complain only *then* about hard links which are still
in evidence even after killing off all the unreachable paths.
Reported-by: Liu Song <liu.song11@zte.com.cn>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit d65e96441a3fa29813f447f69621932f774561b9
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Mon Feb 1 12:37:20 2016 +0000
jffs2: Fix page lock / f->sem deadlock
commit 49e91e7079febe59a20ca885a87dd1c54240d0f1 upstream.
With this fix, all code paths should now be obtaining the page lock before
f->sem.
Reported-by: Szabó Tamás <sztomi89@gmail.com>
Tested-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 1ed7bb8bb842261389701c3ee3dc4b59259b5a0e
Author: Thomas Betker <thomas.betker@rohde-schwarz.com>
Date: Tue Nov 10 22:18:15 2015 +0100
Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin"
commit 157078f64b8a9cd7011b6b900b2f2498df850748 upstream.
This reverts commit 5ffd3412ae55
("jffs2: Fix lock acquisition order bug in jffs2_write_begin").
The commit modified jffs2_write_begin() to remove a deadlock with
jffs2_garbage_collect_live(), but this introduced new deadlocks found
by multiple users. page_lock() actually has to be called before
mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
jffs2_write_end() and jffs2_readpage() are called with the page locked,
and they acquire c->alloc_sem and f->sem, resp.
In other words, the lock order in jffs2_write_begin() was correct, and
it is the jffs2_garbage_collect_live() path that has to be changed.
Revert the commit to get rid of the new deadlocks, and to clear the way
for a better fix of the original deadlock.
Reported-by: Deng Chao <deng.chao1@zte.com.cn>
Reported-by: Ming Liu <liu.ming50@gmail.com>
Reported-by: wangzaiwei <wangzaiwei@top-vision.cn>
Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 7dabf7e04ad03585ddfa7bc9d5e982ab79521a02
Author: Todd E Brandt <todd.e.brandt@linux.intel.com>
Date: Wed Mar 2 16:05:29 2016 -0800
PM / sleep / x86: Fix crash on graph trace through x86 suspend
commit 92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 upstream.
Pause/unpause graph tracing around do_suspend_lowlevel as it has
inconsistent call/return info after it jumps to the wakeup vector.
The graph trace buffer will otherwise become misaligned and
may eventually crash and hang on suspend.
To reproduce the issue and test the fix:
Run a function_graph trace over suspend/resume and set the graph
function to suspend_devices_and_enter. This consistently hangs the
system without this fix.
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 54709aebcea1709772a302a9592d52a8252bc08d
Author: Harvey Hunt <harvey.hunt@imgtec.com>
Date: Wed Feb 24 15:16:43 2016 +0000
libata: Align ata_device's id on a cacheline
commit 4ee34ea3a12396f35b26d90a094c75db95080baa upstream.
The id buffer in ata_device is a DMA target, but it isn't explicitly
cacheline aligned. Due to this, adjacent fields can be overwritten with
stale data from memory on non coherent architectures. As a result, the
kernel is sometimes unable to communicate with an ATA device.
Fix this by ensuring that the id buffer is cacheline aligned.
This issue is similar to that fixed by Commit 84bda12af31f
("libata: align ap->sector_buf").
Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit a4b93e738aa086a155cbf143d47c88e63ab845a5
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Feb 11 14:16:27 2016 +0100
libata: fix HDIO_GET_32BIT ioctl
commit 287e6611ab1eac76c2c5ebf6e345e04c80ca9c61 upstream.
As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
work correctly in compat mode with libata.
I have investigated the issue further and found multiple problems
that all appeared with the same commit that originally introduced
HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
a 'long' variable containing either 0 or 1 to user space.
The problems with this are:
* On big-endian machines, this will always write a zero because it
stores the wrong byte into user space.
* In compat mode, the upper three bytes of the variable are updated
by the compat_hdio_ioctl() function, but they now contain
uninitialized stack data.
* The hdparm tool calling this ioctl uses a 'static long' variable
to store the result. This means at least the upper bytes are
initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
would fill them with data that remains stale when the low byte
is overwritten. Fortunately libata doesn't implement any of the
affected ioctl commands, so this would only happen when we query
both an IDE and an ATA device in the same command such as
"hdparm -N -c /dev/hda /dev/sda"
* The libata code for unknown reasons started using ATA_IOC_GET_IO32
and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
while the ioctl commands that were added later use the normal
HDIO_* names. This is harmless but rather confusing.
This addresses all four issues by changing the code to use put_user()
on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
does, and by clarifying the names of the ioctl commands.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Soohoon Lee <Soohoon.Lee@f5.com>
Tested-by: Soohoon Lee <Soohoon.Lee@f5.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 1f3193db2abc73f8eb273445bd6fbd42a8d3dd40
Author: Timothy Pearson <tpearson@raptorengineeringinc.com>
Date: Fri Feb 26 15:29:32 2016 -0600
drm/ast: Fix incorrect register check for DRAM width
commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 upstream.
During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.
Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit acdb842ee6a5c997c3ea1c4e393bd71aa093b139
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed Feb 24 12:18:49 2016 -0800
x86/entry/compat: Add missing CLAC to entry_INT80_32
commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa upstream.
This doesn't seem to fix a regression -- I don't think the CLAC was
ever there.
I double-checked in a debugger: entries through the int80 gate do
not automatically clear AC.
Stable maintainers: I can provide a backport to 4.3 and earlier if
needed. This needs to be backported all the way to 3.10.
Reported-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access")
Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ kamal: backport to 3.10 through 3.19-stable: file rename; context ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 7532136e1a5e84d6e396c3057e33e23d56efe268
Author: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Date: Tue Feb 23 13:03:30 2016 +0100
iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered
commit 38e45d02ea9f194b89d6bf41e52ccafc8e2c2b47 upstream.
The setup code for the performance counters in the AMD IOMMU driver
tests whether the counters can be written. It tests to setup a counter
for device 00:00.0, which fails on systems where this particular device
is not covered by the IOMMU.
Fix this by not relying on device 00:00.0 but only on the IOMMU being
present.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 9a5d07a53043fbd30f679526f8a4d8220dca5aab
Author: Pavel Shilovsky <pshilovsky@samba.org>
Date: Sat Feb 27 11:58:18 2016 +0300
CIFS: Fix SMB2+ interim response processing for read requests
commit 6cc3b24235929b54acd5ecc987ef11a425bd209e upstream.
For interim responses we only need to parse a header and update
a number credits. Now it is done for all SMB2+ command except
SMB2_READ which is wrong. Fix this by adding such processing.
Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Tested-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 18bb5d79a23da04c48c706f85294468c917d7974
Author: Justin Maggard <jmaggard10@gmail.com>
Date: Tue Feb 9 15:52:08 2016 -0800
cifs: fix out-of-bounds access in lease parsing
commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.
When opening a file, SMB2_open() attempts to parse the lease state from the
SMB2 CREATE Response. However, the parsing code was not careful to ensure
that the create contexts are not empty or invalid, which can lead to out-
of-bounds memory access. This can be seen easily by trying
to read a file from a OSX 10.11 SMB3 server. Here is sample crash output:
BUG: unable to handle kernel paging request at ffff8800a1a77cc6
IP: [<ffffffff8828a734>] SMB2_open+0x804/0x960
PGD 8f77067 PUD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
Hardware name: NETGEAR ReadyNAS 314 /ReadyNAS 314 , BIOS 4.6.5 10/11/2012
task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
RIP: 0010:[<ffffffff8828a734>] [<ffffffff8828a734>] SMB2_open+0x804/0x960
RSP: 0018:ffff88005b31fa08 EFLAGS: 00010282
RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
FS: 00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
Stack:
ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
Call Trace:
[<ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0
[<ffffffff8828cf68>] smb2_open_file+0x98/0x210
[<ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0
[<ffffffff882685f4>] cifs_open+0x2a4/0x720
[<ffffffff88122cef>] do_dentry_open+0x1ff/0x310
[<ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30
[<ffffffff88123d92>] vfs_open+0x52/0x60
[<ffffffff88131dd0>] path_openat+0x170/0xf70
[<ffffffff88097d48>] ? remove_wait_queue+0x48/0x50
[<ffffffff88133a29>] do_filp_open+0x79/0xd0
[<ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170
[<ffffffff881240c4>] do_sys_open+0x114/0x1e0
[<ffffffff881241a9>] SyS_open+0x19/0x20
[<ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a
Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
RIP [<ffffffff8828a734>] SMB2_open+0x804/0x960
RSP <ffff88005b31fa08>
CR2: ffff8800a1a77cc6
---[ end trace d9f69ba64feee469 ]---
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 4af56fdd2f6559b63ad140127553b6edb2c173aa
Author: Michal Marek <mmarek@suse.com>
Date: Wed Dec 9 15:08:21 2015 +0100
genksyms: Handle string literals with spaces in reference files
commit a78f70e8d65e88b9f631d073f68cb26dcd746298 upstream.
The reference files use spaces to separate tokens, however, we must
preserve spaces inside string literals. Currently the only case in the
tree is struct edac_raw_error_desc in <linux/edac.h>:
$ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes
$ mv drivers/edac/amd64_edac.{symtypes,symref}
$ KBUILD_SYMTYPES=1 make -s drivers/edac/amd64_edac.symtypes
drivers/edac/amd64_edac.c:527: warning: amd64_get_dram_hole_info: modversion changed because of changes in struct edac_raw_error_desc
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 2dc65c727a5dfab09f0104f4b68989ad8d0ea946
Author: Vasu Dev <vasu.dev@intel.com>
Date: Mon Nov 23 10:31:25 2015 -0800
ixgbe: fix broken PFC with X550
commit cb78cf12d6e90f57f6e7d090867ef19b6a189dde upstream.
PFC is configuration is skipped for X550 devices due to a incorrect
device id check, fixing that to include X550 PFC configuration.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit d4b9251744b47d562363bfa7ff005b938f705c8c
Author: Vasu Dev <vasu.dev@intel.com>
Date: Mon Nov 23 10:31:01 2015 -0800
ixgbe: use correct FCoE DDP max check
commit f10166aba2def9bc6443290231c60f7e2f70129b upstream.
Use fcoe_ddp_xid from netdev as this is correctly set for different
device IDs to avoid DDP skip error on X550 as "xid=0x20b out-of-range"
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit e3123e4a9726d0160a15ab09c512fcee95d9f2d3
Author: Al Cooper <alcooperx@gmail.com>
Date: Wed Dec 2 14:55:07 2015 -0500
usb: Add connected retry on resume for non SS devices
commit 6b82b1223e3b14afd89d167795671a9f4f77b2f0 upstream.
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit e1d5059a4e88c44a9fe45a266adf8978735dde32
Author: Oliver Neukum <oneukum@suse.com>
Date: Tue Oct 27 09:51:34 2015 -0200
[media] usbvision fix overflow of interfaces array
commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream.
This fixes the crash reported in:
http://seclists.org/bugtraq/2015/Oct/35
The interface number needs a sanity check.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 0a164a5b94ebb28e32bceb0279f90a984b68eedd
Author: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Date: Wed Oct 28 16:02:54 2015 -0500
USB: cp210x: work around cp2108 GET_LINE_CTL bug
commit d0bf1ff0ae322aca59b00b9a2ad121d35a77e78f upstream.
Add helper to access line-control register in order to work around a
cp2108 GET_LINE_CTL bug.
cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
the register, it reads it, modifies some bits and writes back. Because the
read bytes were swapped, this often results in an invalid value to be
written. In turn, this causes cp2108 respond with a stall. The stall
sometimes doesn't clear properly and cp2108 starts responding to following
valid commands also with stalls, effectively failing.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
[johan: amend commit message, modify probe error handling ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit c1b189c0af6dccc9f54dcd78794a94a70b48fd09
Author: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Date: Wed Oct 28 16:02:34 2015 -0500
USB: cp210x: relocate private data from USB interface to port
commit e2ae67a3b55188b0342522d8139acf013feb2a69 upstream.
This change is preparation for implementing a cp2108 bug workaround.
The workaround requires storing some private data. Right now the data is
attached to the USB interface and allocated in the attach() callback.
The bug detection requires USB I/O which is done easier from port_probe()
callback rather than attach(). Since the USB access functions take port
as a parameter, and since the private data is used exclusively by these
functions, it can be allocated in port_probe(). Also, all cp210x devices
have exactly 1 port per USB iterface, so moving private data from the USB
interface to port is trivial.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit bb91798fe25f197f3d39b06370711aac21b60e62
Author: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Date: Wed Oct 28 16:02:03 2015 -0500
USB: cp210x: flush device queues at close
commit ebfb319bb601e501f77809a83b0b69b529c22a8d upstream.
Flush all device queues at close in order to work around a cp2108 Tx
queue bug.
Occasionally, writing data and immediately closing the port makes cp2108
stop responding. The device has to be unplugged to clear the error.
The failure is induced by shutting down the device while its Tx queue
still has unsent data. This condition is avoided by issuing PURGE command
from the close() callback.
This change is applied to all cp210x devices. Clearing internal queues on
close is generally good.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
[johan: amend commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 9bbf01bec5d3aa651a4cb154449439d65bebb622
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed Feb 3 02:11:03 2016 +0100
unix: correctly track in-flight fds in sending process user_struct
commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 upstream.
The commit referenced in the Fixes tag incorrectly accounted the number
of in-flight fds over a unix domain socket to the original opener
of the file-descriptor. This allows another process to arbitrary
deplete the original file-openers resource limit for the maximum of
open files. Instead the sending processes and its struct cred should
be credited.
To do so, we add a reference counted struct user_struct pointer to the
scm_fp_list and use it to account for the number of inflight unix fds.
Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Michal Kubecek <mkubecek@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
commit 3d024dcef2548028e9f9b7876a544e6e0af00175
Author: willy tarreau <w@1wt.eu>
Date: Sun Jan 10 07:54:56 2016 +0100
unix: properly account for FDs passed over unix sockets
[ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]
It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.
This change addresses this problem by keeping track of the number of FDs
in flight per user and preventing non-privileged processes from having
more FDs in flight than their configured FD limit.
Cc: Michal Kubecek <mkubecek@suse.com>
Reported-by: socketpair@gmail.com
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 377b71e18f20d69b0df301ce7040554f40ba9651
Author: NeilBrown <neilb@suse.com>
Date: Mon Mar 7 10:19:02 2016 +0100
nfsd: fix problem with setting ACL on directories
This is a regression of 3.12 stable commit
ba1816b40a87a3f3c4ca9cd54a593a10d87bd391 (nfsd: fix NFS regression).
If a non-inherited ACL is set on a directory, nfsd will try to set the Posix
default ACL to NULL. This gets converted to "" by generic_setxattr().
As "" is not a valid posix acl attribute value, this results in an error.
So instead of setting the xattr to NULL, remove it.
Fixes: ba1816b40a ("nfsd: fix NFS regression")
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: Sergio Gelato <Sergio.Gelato@astro.su.se>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>