Linux 3.10.101 (accumulative patch)

commit 326a1b2d50cbe1f890e56ab60b9215cd30053f5a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 16 08:41:47 2016 -0700

    Linux 3.10.101

commit 1f2493fcd87bd810c608aa7976388157852eadb2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 12 21:30:16 2016 -0800

    Revert: "crypto: af_alg - Disallow bind/setkey/... after accept(2)"

    This reverts commit 5a707f0972e1c9d8a4a921ddae79d0f9dc36a341 which is
    commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.

    It's been widely reported that this patch breaks existing userspace
    applications when backported to the stable kernel releases.  As no fix
    seems to be forthcoming, just revert it to let systems work again.

    Reported-by: "J. Paul Reed" <preed@sigkill.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6692b5c5d7a2178bfa17b9e1dff205aaaa51342
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8bedaa47abfc566933d5c0c96c39bee95cb0deb
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15b988cf26966e7926173bc4ef77010c40941bf2
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b35014c77e1ba732617c83ab6705298302bd09f
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d591b6da723e6b09b57a2b2386d00fe095bf034b
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44f21ed11c92f28b44fe283b8d0fd7899bc35430
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6d535a35f5a3e842e02d13f84a729ef98f20952
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0b5aae480e53e26c0739241144eaa0e2e56a4fc
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73c1d981f04cdee52466ea0e5fc0d04c76ad6f49
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4f8295ef4516a699997649894ff3a62f4d151d6
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0103c34fed88414808dfbc500b9066ab867e3b6c
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb1df1e59413b1dbe9b71df7651100c7b5ab67d3
Author: Chris Bainbridge <chris.bainbridge@gmail.com>
Date:   Wed Jan 27 15:46:18 2016 +0000

    mac80211: fix use of uninitialised values in RX aggregation

    commit f39ea2690bd61efec97622c48323f40ed6e16317 upstream.

    Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
    initialize the "removed" field (all others are initialized
    manually). That fixes:

    UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
    load of value 2 is not a valid value for type '_Bool'
    CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
    Workqueue: phy0 rt2x00usb_work_rxdone
     0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
     ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
     ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
    Call Trace:
     [<ffffffff8181d866>] dump_stack+0x45/0x5f
     [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40
     [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
     [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
     [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
     [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
     [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990

    While at it, convert to use sizeof(*tid_agg_rx) instead.

    Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
    Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    [reword commit message, use sizeof(*tid_agg_rx)]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fc40fd11d629a1bda71be5c5a7380723a021e97
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86ac250ac18e79381ac0b5631987dda836b3de69
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f2ba1da9ccf08b7ab3bd506a6788f63ace870df
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1934f322b9654faccba965709279ea3473fa01e4
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 618fedd40dcd9b43026d6749d6bf0674f008fdca
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

0 files changed, 0 insertions, 0 deletions