1. 31 Jan, 2018 40 commits
    • Alexei Starovoitov's avatar
      bpf: introduce BPF_JIT_ALWAYS_ON config · a3d6dd6a
      Alexei Starovoitov authored
      [ upstream commit 290af866
      
       ]
      
      The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
      
      A quote from goolge project zero blog:
      "At this point, it would normally be necessary to locate gadgets in
      the host kernel code that can be used to actually leak data by reading
      from an attacker-controlled location, shifting and masking the result
      appropriately and then using the result of that as offset to an
      attacker-controlled address for a load. But piecing gadgets together
      and figuring out which ones work in a speculation context seems annoying.
      So instead, we decided to use the eBPF interpreter, which is built into
      the host kernel - while there is no legitimate way to invoke it from inside
      a VM, the presence of the code in the host kernel's text section is sufficient
      to make it usable for the attack, just like with ordinary ROP gadgets."
      
      To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
      option that removes interpreter from the kernel in favor of JIT-only mode.
      So far eBPF JIT is supported by:
      x64, arm64, arm32, sparc64, s390, powerpc64, mips64
      
      The start of JITed program is randomized and code page is marked as read-only.
      In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
      
      v2->v3:
      - move __bpf_prog_ret0 under ifdef (Daniel)
      
      v1->v2:
      - fix init order, test_bpf and cBPF (Daniel's feedback)
      - fix offloaded bpf (Jakub's feedback)
      - add 'return 0' dummy in case something can invoke prog->bpf_func
      - retarget bpf tree. For bpf-next the patch would need one extra hunk.
        It will be sent when the trees are merged back to net-next
      
      Considered doing:
        int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
      but it seems better to land the patch as-is and in bpf-next remove
      bpf_jit_enable global variable from all JITs, consolidate in one place
      and remove this jit_init() function.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3d6dd6a
    • Alexei Starovoitov's avatar
      bpf: fix bpf_tail_call() x64 JIT · 5226bb3b
      Alexei Starovoitov authored
      [ upstream commit 90caccdd ]
      
      - bpf prog_array just like all other types of bpf array accepts 32-bit index.
        Clarify that in the comment.
      - fix x64 JIT of bpf_tail_call which was incorrectly loading 8 instead of 4 bytes
      - tighten corresponding check in the interpreter to stay consistent
      
      The JIT bug can be triggered after introduction of BPF_F_NUMA_NODE flag
      in commit 96eabe7a
      
       in 4.14. Before that the map_flags would stay zero and
      though JIT code is wrong it will check bounds correctly.
      Hence two fixes tags. All other JITs don't have this problem.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Fixes: 96eabe7a ("bpf: Allow selecting numa node during map creation")
      Fixes: b52f00e6
      
       ("x86: bpf_jit: implement bpf_tail_call() helper")
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5226bb3b
    • Eric Dumazet's avatar
      x86: bpf_jit: small optimization in emit_bpf_tail_call() · c964ad34
      Eric Dumazet authored
      [ upstream commit 84ccac6e
      
       ]
      
      Saves 4 bytes replacing following instructions :
      
      lea rax, [rsi + rdx * 8 + offsetof(...)]
      mov rax, qword ptr [rax]
      cmp rax, 0
      
      by :
      
      mov rax, [rsi + rdx * 8 + offsetof(...)]
      test rax, rax
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c964ad34
    • Thomas Gleixner's avatar
      hrtimer: Reset hrtimer cpu base proper on CPU hotplug · c98ff729
      Thomas Gleixner authored
      commit d5421ea4 upstream.
      
      The hrtimer interrupt code contains a hang detection and mitigation
      mechanism, which prevents that a long delayed hrtimer interrupt causes a
      continous retriggering of interrupts which prevent the system from making
      progress. If a hang is detected then the timer hardware is programmed with
      a certain delay into the future and a flag is set in the hrtimer cpu base
      which prevents newly enqueued timers from reprogramming the timer hardware
      prior to the chosen delay. The subsequent hrtimer interrupt after the delay
      clears the flag and resumes normal operation.
      
      If such a hang happens in the last hrtimer interrupt before a CPU is
      unplugged then the hang_detected flag is set and stays that way when the
      CPU is plugged in again. At that point the timer hardware is not armed and
      it cannot be armed because the hang_detected flag is still active, so
      nothing clears that flag. As a consequence the CPU does not receive hrtimer
      interrupts and no timers expire on that CPU which results in RCU stalls and
      other malfunctions.
      
      Clear the flag along with some other less critical members of the hrtimer
      cpu base to ensure starting from a clean state when a CPU is plugged in.
      
      Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the
      root cause of that hard to reproduce heisenbug. Once understood it's
      trivial and certainly justifies a brown paperbag.
      
      Fixes: 41d2e494
      
       ("hrtimer: Tune hrtimer_interrupt hang logic")
      Reported-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Sewior <bigeasy@linutronix.de>
      Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c98ff729
    • Jia Zhang's avatar
      x86/microcode/intel: Extend BDW late-loading further with LLC size check · 9f3a6cad
      Jia Zhang authored
      commit 7e702d17 upstream.
      
      Commit b94b7373 ("x86/microcode/intel: Extend BDW late-loading with a
      revision check") reduced the impact of erratum BDF90 for Broadwell model
      79.
      
      The impact can be reduced further by checking the size of the last level
      cache portion per core.
      
      Tony: "The erratum says the problem only occurs on the large-cache SKUs.
      So we only need to avoid the update if we are on a big cache SKU that is
      also running old microcode."
      
      For more details, see erratum BDF90 in document #334165 (Intel Xeon
      Processor E7-8800/4800 v4 Product Family Specification Update) from
      September 2017.
      
      Fixes: b94b7373
      
       ("x86/microcode/intel: Extend BDW late-loading with a revision check")
      Signed-off-by: default avatarJia Zhang <zhang.jia@linux.alibaba.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Link: https://lkml.kernel.org/r/1516321542-31161-1-git-send-email-zhang.jia@linux.alibaba.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f3a6cad
    • Xiao Liang's avatar
      perf/x86/amd/power: Do not load AMD power module on !AMD platforms · dc1932c6
      Xiao Liang authored
      commit 40d4071c upstream.
      
      The AMD power module can be loaded on non AMD platforms, but unload fails
      with the following Oops:
      
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: __list_del_entry_valid+0x29/0x90
       Call Trace:
        perf_pmu_unregister+0x25/0xf0
        amd_power_pmu_exit+0x1c/0xd23 [power]
        SyS_delete_module+0x1a8/0x2b0
        ? exit_to_usermode_loop+0x8f/0xb0
        entry_SYSCALL_64_fastpath+0x20/0x83
      
      Return -ENODEV instead of 0 from the module init function if the CPU does
      not match.
      
      Fixes: c7ab62bf
      
       ("perf/x86/amd/power: Add AMD accumulated power reporting mechanism")
      Signed-off-by: default avatarXiao Liang <xiliang@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20180122061252.6394-1-xiliang@redhat.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc1932c6
    • Eric Dumazet's avatar
      flow_dissector: properly cap thoff field · eecfa2ee
      Eric Dumazet authored
      
      [ Upstream commit d0c081b4 ]
      
      syzbot reported yet another crash [1] that is caused by
      insufficient validation of DODGY packets.
      
      Two bugs are happening here to trigger the crash.
      
      1) Flow dissection leaves with incorrect thoff field.
      
      2) skb_probe_transport_header() sets transport header to this invalid
      thoff, even if pointing after skb valid data.
      
      3) qdisc_pkt_len_init() reads out-of-bound data because it
      trusts tcp_hdrlen(skb)
      
      Possible fixes :
      
      - Full flow dissector validation before injecting bad DODGY packets in
      the stack.
       This approach was attempted here : https://patchwork.ozlabs.org/patch/
      861874/
      
      - Have more robust functions in the core.
        This might be needed anyway for stable versions.
      
      This patch fixes the flow dissection issue.
      
      [1]
      CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:355 [inline]
       kasan_report+0x23b/0x360 mm/kasan/report.c:413
       __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432
       __tcp_hdrlen include/linux/tcp.h:35 [inline]
       tcp_hdrlen include/linux/tcp.h:40 [inline]
       qdisc_pkt_len_init net/core/dev.c:3160 [inline]
       __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3554
       packet_snd net/packet/af_packet.c:2943 [inline]
       packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968
       sock_sendmsg_nosec net/socket.c:628 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:638
       sock_write_iter+0x31a/0x5d0 net/socket.c:907
       call_write_iter include/linux/fs.h:1776 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:482
       vfs_write+0x189/0x510 fs/read_write.c:544
       SYSC_write fs/read_write.c:589 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:581
       entry_SYSCALL_64_fastpath+0x1f/0x96
      
      Fixes: 34fad54c ("net: __skb_flow_dissect() must cap its return value")
      Fixes: a6e544b0
      
       ("flow_dissector: Jump to exit code in __skb_flow_dissect")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eecfa2ee
    • Cong Wang's avatar
      tun: fix a memory leak for tfile->tx_array · 18717ee2
      Cong Wang authored
      
      [ Upstream commit 4df0bfc7
      
       ]
      
      tfile->tun could be detached before we close the tun fd,
      via tun_detach_all(), so it should not be used to check for
      tfile->tx_array.
      
      As Jason suggested, we probably have to clean it up
      unconditionally both in __tun_deatch() and tun_detach_all(),
      but this requires to check if it is initialized or not.
      Currently skb_array_cleanup() doesn't have such a check,
      so I check it in the caller and introduce a helper function,
      it is a bit ugly but we can always improve it in net-next.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Fixes: 1576d986
      
       ("tun: switch to use skb array for tx")
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18717ee2
    • Yuval Mintz's avatar
      mlxsw: spectrum_router: Don't log an error on missing neighbor · 1105145c
      Yuval Mintz authored
      
      [ Upstream commit 1ecdaea0 ]
      
      Driver periodically samples all neighbors configured in device
      in order to update the kernel regarding their state. When finding
      an entry configured in HW that doesn't show in neigh_lookup()
      driver logs an error message.
      This introduces a race when removing multiple neighbors -
      it's possible that a given entry would still be configured in HW
      as its removal is still being processed but is already removed
      from the kernel's neighbor tables.
      
      Simply remove the error message and gracefully accept such events.
      
      Fixes: c723c735 ("mlxsw: spectrum_router: Periodically update the kernel's neigh table")
      Fixes: 60f040ca
      
       ("mlxsw: spectrum_router: Periodically dump active IPv6 neighbours")
      Signed-off-by: default avatarYuval Mintz <yuvalm@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1105145c
    • Willem de Bruijn's avatar
      gso: validate gso_type in GSO handlers · 3110e213
      Willem de Bruijn authored
      
      [ Upstream commit 121d57af ]
      
      Validate gso_type during segmentation as SKB_GSO_DODGY sources
      may pass packets where the gso_type does not match the contents.
      
      Syzkaller was able to enter the SCTP gso handler with a packet of
      gso_type SKB_GSO_TCPV4.
      
      On entry of transport layer gso handlers, verify that the gso_type
      matches the transport protocol.
      
      Fixes: 90017acc ("sctp: Add GSO support")
      Link: http://lkml.kernel.org/r/<001a1137452496ffc305617e5fe0@google.com
      
      >
      Reported-by: syzbot+fee64147a25aecd48055@syzkaller.appspotmail.com
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3110e213
    • Alexey Kodanev's avatar
      ip6_gre: init dev->mtu and dev->hard_header_len correctly · cc99c6d5
      Alexey Kodanev authored
      
      [ Upstream commit 128bb975 ]
      
      Commit b05229f4 ("gre6: Cleanup GREv6 transmit path,
      call common GRE functions") moved dev->mtu initialization
      from ip6gre_tunnel_setup() to ip6gre_tunnel_init(), as a
      result, the previously set values, before ndo_init(), are
      reset in the following cases:
      
      * rtnl_create_link() can update dev->mtu from IFLA_MTU
        parameter.
      
      * ip6gre_tnl_link_config() is invoked before ndo_init() in
        netlink and ioctl setup, so ndo_init() can reset MTU
        adjustments with the lower device MTU as well, dev->mtu
        and dev->hard_header_len.
      
        Not applicable for ip6gretap because it has one more call
        to ip6gre_tnl_link_config(tunnel, 1) in ip6gre_tap_init().
      
      Fix the first case by updating dev->mtu with 'tb[IFLA_MTU]'
      parameter if a user sets it manually on a device creation,
      and fix the second one by moving ip6gre_tnl_link_config()
      call after register_netdevice().
      
      Fixes: b05229f4 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
      Fixes: db2ec95d
      
       ("ip6_gre: Fix MTU setting")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc99c6d5
    • Ivan Vecera's avatar
      be2net: restore properly promisc mode after queues reconfiguration · 1711ba16
      Ivan Vecera authored
      
      [ Upstream commit 52acf064 ]
      
      The commit 62219066 ("be2net: Request RSS capability of Rx interface
      depending on number of Rx rings") modified be_update_queues() so the
      IFACE (HW representation of the netdevice) is destroyed and then
      re-created. This causes a regression because potential promiscuous mode
      is not restored properly during be_open() because the driver thinks
      that the HW has promiscuous mode already enabled.
      
      Note that Lancer is not affected by this bug because RX-filter flags are
      disabled during be_close() for this chipset.
      
      Cc: Sathya Perla <sathya.perla@broadcom.com>
      Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Cc: Somnath Kotur <somnath.kotur@broadcom.com>
      
      Fixes: 62219066
      
       ("be2net: Request RSS capability of Rx interface depending on number of Rx rings")
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1711ba16
    • Guillaume Nault's avatar
      ppp: unlock all_ppp_mutex before registering device · 00f9e47c
      Guillaume Nault authored
      
      [ Upstream commit 0171c418 ]
      
      ppp_dev_uninit(), which is the .ndo_uninit() handler of PPP devices,
      needs to lock pn->all_ppp_mutex. Therefore we mustn't call
      register_netdevice() with pn->all_ppp_mutex already locked, or we'd
      deadlock in case register_netdevice() fails and calls .ndo_uninit().
      
      Fortunately, we can unlock pn->all_ppp_mutex before calling
      register_netdevice(). This lock protects pn->units_idr, which isn't
      used in the device registration process.
      
      However, keeping pn->all_ppp_mutex locked during device registration
      did ensure that no device in transient state would be published in
      pn->units_idr. In practice, unlocking it before calling
      register_netdevice() doesn't change this property: ppp_unit_register()
      is called with 'ppp_mutex' locked and all searches done in
      pn->units_idr hold this lock too.
      
      Fixes: 8cb775bc
      
       ("ppp: fix device unregistration upon netns deletion")
      Reported-and-tested-by: syzbot+367889b9c9e279219175@syzkaller.appspotmail.com
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00f9e47c
    • Jim Westfall's avatar
      ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY · 260eb694
      Jim Westfall authored
      
      [ Upstream commit cd9ff4de ]
      
      Map all lookup neigh keys to INADDR_ANY for loopback/point-to-point devices
      to avoid making an entry for every remote ip the device needs to talk to.
      
      This used the be the old behavior but became broken in a263b309
      (ipv4: Make neigh lookups directly in output packet path) and later removed
      in 0bb4087c
      
       (ipv4: Fix neigh lookup keying over loopback/point-to-point
      devices) because it was broken.
      Signed-off-by: default avatarJim Westfall <jwestfall@surrealistic.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      260eb694
    • Jim Westfall's avatar
      net: Allow neigh contructor functions ability to modify the primary_key · 014510b1
      Jim Westfall authored
      
      [ Upstream commit 096b9854
      
       ]
      
      Use n->primary_key instead of pkey to account for the possibility that a neigh
      constructor function may have modified the primary_key value.
      Signed-off-by: default avatarJim Westfall <jwestfall@surrealistic.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      014510b1
    • Neil Horman's avatar
      vmxnet3: repair memory leak · 66c16a22
      Neil Horman authored
      
      [ Upstream commit 848b1598 ]
      
      with the introduction of commit
      b0eb57cb
      
      , it appears that rq->buf_info
      is improperly handled.  While it is heap allocated when an rx queue is
      setup, and freed when torn down, an old line of code in
      vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0]
      being set to NULL prior to its being freed, causing a memory leak, which
      eventually exhausts the system on repeated create/destroy operations
      (for example, when  the mtu of a vmxnet3 interface is changed
      frequently.
      
      Fix is pretty straight forward, just move the NULL set to after the
      free.
      
      Tested by myself with successful results
      
      Applies to net, and should likely be queued for stable, please
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-By: boyang@redhat.com
      CC: boyang@redhat.com
      CC: Shrikrishna Khare <skhare@vmware.com>
      CC: "VMware, Inc." <pv-drivers@vmware.com>
      CC: David S. Miller <davem@davemloft.net>
      Acked-by: default avatarShrikrishna Khare <skhare@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66c16a22
    • Cong Wang's avatar
      tipc: fix a memory leak in tipc_nl_node_get_link() · 0e52703d
      Cong Wang authored
      
      [ Upstream commit 59b36613
      
       ]
      
      When tipc_node_find_by_name() fails, the nlmsg is not
      freed.
      
      While on it, switch to a goto label to properly
      free it.
      
      Fixes: be9c086715c ("tipc: narrow down exposure of struct tipc_node")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e52703d
    • Xin Long's avatar
      sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf · 2f056e7d
      Xin Long authored
      
      [ Upstream commit a0ff6600 ]
      
      After commit cea0cc80 ("sctp: use the right sk after waking up from
      wait_buf sleep"), it may change to lock another sk if the asoc has been
      peeled off in sctp_wait_for_sndbuf.
      
      However, the asoc's new sk could be already closed elsewhere, as it's in
      the sendmsg context of the old sk that can't avoid the new sk's closing.
      If the sk's last one refcnt is held by this asoc, later on after putting
      this asoc, the new sk will be freed, while under it's own lock.
      
      This patch is to revert that commit, but fix the old issue by returning
      error under the old sk's lock.
      
      Fixes: cea0cc80
      
       ("sctp: use the right sk after waking up from wait_buf sleep")
      Reported-by: syzbot+ac6ea7baa4432811eb50@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f056e7d
    • Xin Long's avatar
      sctp: do not allow the v4 socket to bind a v4mapped v6 address · 8e3534ea
      Xin Long authored
      
      [ Upstream commit c5006b8a ]
      
      The check in sctp_sockaddr_af is not robust enough to forbid binding a
      v4mapped v6 addr on a v4 socket.
      
      The worse thing is that v4 socket's bind_verify would not convert this
      v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4
      socket bound a v6 addr.
      
      This patch is to fix it by doing the common sa.sa_family check first,
      then AF_INET check for v4mapped v6 addrs.
      
      Fixes: 7dab83de
      
       ("sctp: Support ipv6only AF_INET6 sockets.")
      Reported-by: syzbot+7b7b518b1228d2743963@syzkaller.appspotmail.com
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e3534ea
    • Francois Romieu's avatar
      r8169: fix memory corruption on retrieval of hardware statistics. · 0f51492d
      Francois Romieu authored
      
      [ Upstream commit a78e9366
      
       ]
      
      Hardware statistics retrieval hurts in tight invocation loops.
      
      Avoid extraneous write and enforce strict ordering of writes targeted to
      the tally counters dump area address registers.
      Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Tested-by: default avatarOliver Freyermuth <o.freyermuth@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f51492d
    • Guillaume Nault's avatar
      pppoe: take ->needed_headroom of lower device into account on xmit · 1bd21b15
      Guillaume Nault authored
      
      [ Upstream commit 02612bb0 ]
      
      In pppoe_sendmsg(), reserving dev->hard_header_len bytes of headroom
      was probably fine before the introduction of ->needed_headroom in
      commit f5184d26 ("net: Allow netdevices to specify needed head/tailroom").
      
      But now, virtual devices typically advertise the size of their overhead
      in dev->needed_headroom, so we must also take it into account in
      skb_reserve().
      Allocation size of skb is also updated to take dev->needed_tailroom
      into account and replace the arbitrary 32 bytes with the real size of
      a PPPoE header.
      
      This issue was discovered by syzbot, who connected a pppoe socket to a
      gre device which had dev->header_ops->create == ipgre_header and
      dev->hard_header_len == 0. Therefore, PPPoE didn't reserve any
      headroom, and dev_hard_header() crashed when ipgre_header() tried to
      prepend its header to skb->data.
      
      skbuff: skb_under_panic: text:000000001d390b3a len:31 put:24
      head:00000000d8ed776f data:000000008150e823 tail:0x7 end:0xc0 dev:gre0
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:104!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 3670 Comm: syzkaller801466 Not tainted
      4.15.0-rc7-next-20180115+ #97
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100
      RSP: 0018:ffff8801d9bd7840 EFLAGS: 00010282
      RAX: 0000000000000083 RBX: ffff8801d4f083c0 RCX: 0000000000000000
      RDX: 0000000000000083 RSI: 1ffff1003b37ae92 RDI: ffffed003b37aefc
      RBP: ffff8801d9bd78a8 R08: 1ffff1003b37ae8a R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff86200de0
      R13: ffffffff84a981ad R14: 0000000000000018 R15: ffff8801d2d34180
      FS:  00000000019c4880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000208bc000 CR3: 00000001d9111001 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        skb_under_panic net/core/skbuff.c:114 [inline]
        skb_push+0xce/0xf0 net/core/skbuff.c:1714
        ipgre_header+0x6d/0x4e0 net/ipv4/ip_gre.c:879
        dev_hard_header include/linux/netdevice.h:2723 [inline]
        pppoe_sendmsg+0x58e/0x8b0 drivers/net/ppp/pppoe.c:890
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg+0xca/0x110 net/socket.c:640
        sock_write_iter+0x31a/0x5d0 net/socket.c:909
        call_write_iter include/linux/fs.h:1775 [inline]
        do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
        do_iter_write+0x154/0x540 fs/read_write.c:932
        vfs_writev+0x18a/0x340 fs/read_write.c:977
        do_writev+0xfc/0x2a0 fs/read_write.c:1012
        SYSC_writev fs/read_write.c:1085 [inline]
        SyS_writev+0x27/0x30 fs/read_write.c:1082
        entry_SYSCALL_64_fastpath+0x29/0xa0
      
      Admittedly PPPoE shouldn't be allowed to run on non Ethernet-like
      interfaces, but reserving space for ->needed_headroom is a more
      fundamental issue that needs to be addressed first.
      
      Same problem exists for __pppoe_xmit(), which also needs to take
      dev->needed_headroom into account in skb_cow_head().
      
      Fixes: f5184d26
      
       ("net: Allow netdevices to specify needed head/tailroom")
      Reported-by: syzbot+ed0838d0fa4c4f2b528e20286e6dc63effc7c14d@syzkaller.appspotmail.com
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1bd21b15
    • Dan Streetman's avatar
      net: tcp: close sock if net namespace is exiting · cf67be7a
      Dan Streetman authored
      
      [ Upstream commit 4ee806d5 ]
      
      When a tcp socket is closed, if it detects that its net namespace is
      exiting, close immediately and do not wait for FIN sequence.
      
      For normal sockets, a reference is taken to their net namespace, so it will
      never exit while the socket is open.  However, kernel sockets do not take a
      reference to their net namespace, so it may begin exiting while the kernel
      socket is still open.  In this case if the kernel socket is a tcp socket,
      it will stay open trying to complete its close sequence.  The sock's dst(s)
      hold a reference to their interface, which are all transferred to the
      namespace's loopback interface when the real interfaces are taken down.
      When the namespace tries to take down its loopback interface, it hangs
      waiting for all references to the loopback interface to release, which
      results in messages like:
      
      unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      These messages continue until the socket finally times out and closes.
      Since the net namespace cleanup holds the net_mutex while calling its
      registered pernet callbacks, any new net namespace initialization is
      blocked until the current net namespace finishes exiting.
      
      After this change, the tcp socket notices the exiting net namespace, and
      closes immediately, releasing its dst(s) and their reference to the
      loopback interface, which lets the net namespace continue exiting.
      
      Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
      
      Signed-off-by: default avatarDan Streetman <ddstreet@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf67be7a
    • Eric Dumazet's avatar
      net: qdisc_pkt_len_init() should be more robust · a44d9115
      Eric Dumazet authored
      
      [ Upstream commit 7c68d1a6 ]
      
      Without proper validation of DODGY packets, we might very well
      feed qdisc_pkt_len_init() with invalid GSO packets.
      
      tcp_hdrlen() might access out-of-bound data, so let's use
      skb_header_pointer() and proper checks.
      
      Whole story is described in commit d0c081b4
      
       ("flow_dissector:
      properly cap thoff field")
      
      We have the goal of validating DODGY packets earlier in the stack,
      so we might very well revert this fix in the future.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Reported-by: syzbot+9da69ebac7dddd804552@syzkaller.appspotmail.com
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a44d9115
    • Felix Fietkau's avatar
      net: igmp: fix source address check for IGMPv3 reports · 0ae16964
      Felix Fietkau authored
      
      [ Upstream commit ad23b750 ]
      
      Commit "net: igmp: Use correct source address on IGMPv3 reports"
      introduced a check to validate the source address of locally generated
      IGMPv3 packets.
      Instead of checking the local interface address directly, it uses
      inet_ifa_match(fl4->saddr, ifa), which checks if the address is on the
      local subnet (or equal to the point-to-point address if used).
      
      This breaks for point-to-point interfaces, so check against
      ifa->ifa_local directly.
      
      Cc: Kevin Cernekee <cernekee@chromium.org>
      Fixes: a46182b0
      
       ("net: igmp: Use correct source address on IGMPv3 reports")
      Reported-by: default avatarSebastian Gottschall <s.gottschall@dd-wrt.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ae16964
    • Yuiko Oshino's avatar
      lan78xx: Fix failure in USB Full Speed · 283498b4
      Yuiko Oshino authored
      
      [ Upstream commit a5b1379a ]
      
      Fix initialize the uninitialized tx_qlen to an appropriate value when USB
      Full Speed is used.
      
      Fixes: 55d7de9d
      
       ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: default avatarYuiko Oshino <yuiko.oshino@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      283498b4
    • Eric Dumazet's avatar
      ipv6: ip6_make_skb() needs to clear cork.base.dst · c2ceff11
      Eric Dumazet authored
      
      [ Upstream commit 95ef498d ]
      
      In my last patch, I missed fact that cork.base.dst was not initialized
      in ip6_make_skb() :
      
      If ip6_setup_cork() returns an error, we might attempt a dst_release()
      on some random pointer.
      
      Fixes: 862c03ee
      
       ("ipv6: fix possible mem leaks in ipv6_make_skb()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2ceff11
    • Mike Maloney's avatar
      ipv6: fix udpv6 sendmsg crash caused by too small MTU · fb50d8c9
      Mike Maloney authored
      
      [ Upstream commit 749439bf
      
       ]
      
      The logic in __ip6_append_data() assumes that the MTU is at least large
      enough for the headers.  A device's MTU may be adjusted after being
      added while sendmsg() is processing data, resulting in
      __ip6_append_data() seeing any MTU.  For an mtu smaller than the size of
      the fragmentation header, the math results in a negative 'maxfraglen',
      which causes problems when refragmenting any previous skb in the
      skb_write_queue, leaving it possibly malformed.
      
      Instead sendmsg returns EINVAL when the mtu is calculated to be less
      than IPV6_MIN_MTU.
      
      Found by syzkaller:
      kernel BUG at ./include/linux/skbuff.h:2064!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 14216 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      task: ffff8801d0b68580 task.stack: ffff8801ac6b8000
      RIP: 0010:__skb_pull include/linux/skbuff.h:2064 [inline]
      RIP: 0010:__ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617
      RSP: 0018:ffff8801ac6bf570 EFLAGS: 00010216
      RAX: 0000000000010000 RBX: 0000000000000028 RCX: ffffc90003cce000
      RDX: 00000000000001b8 RSI: ffffffff839df06f RDI: ffff8801d9478ca0
      RBP: ffff8801ac6bf780 R08: ffff8801cc3f1dbc R09: 0000000000000000
      R10: ffff8801ac6bf7a0 R11: 43cb4b7b1948a9e7 R12: ffff8801cc3f1dc8
      R13: ffff8801cc3f1d40 R14: 0000000000001036 R15: dffffc0000000000
      FS:  00007f43d740c700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f7834984000 CR3: 00000001d79b9000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ip6_finish_skb include/net/ipv6.h:911 [inline]
       udp_v6_push_pending_frames+0x255/0x390 net/ipv6/udp.c:1093
       udpv6_sendmsg+0x280d/0x31a0 net/ipv6/udp.c:1363
       inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       SYSC_sendto+0x352/0x5a0 net/socket.c:1750
       SyS_sendto+0x40/0x50 net/socket.c:1718
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x4512e9
      RSP: 002b:00007f43d740bc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00000000007180a8 RCX: 00000000004512e9
      RDX: 000000000000002e RSI: 0000000020d08000 RDI: 0000000000000005
      RBP: 0000000000000086 R08: 00000000209c1000 R09: 000000000000001c
      R10: 0000000000040800 R11: 0000000000000216 R12: 00000000004b9c69
      R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000202c2000
      Code: 9e 01 fe e9 c5 e8 ff ff e8 7f 9e 01 fe e9 4a ea ff ff 48 89 f7 e8 52 9e 01 fe e9 aa eb ff ff e8 a8 b6 cf fd 0f 0b e8 a1 b6 cf fd <0f> 0b 49 8d 45 78 4d 8d 45 7c 48 89 85 78 fe ff ff 49 8d 85 ba
      RIP: __skb_pull include/linux/skbuff.h:2064 [inline] RSP: ffff8801ac6bf570
      RIP: __ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: ffff8801ac6bf570
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarMike Maloney <maloney@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb50d8c9
    • Ben Hutchings's avatar
      ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL · 8b0d3e81
      Ben Hutchings authored
      
      [ Upstream commit e9191ffb ]
      
      Commit 513674b5 ("net: reevalulate autoflowlabel setting after
      sysctl setting") removed the initialisation of
      ipv6_pinfo::autoflowlabel and added a second flag to indicate
      whether this field or the net namespace default should be used.
      
      The getsockopt() handling for this case was not updated, so it
      currently returns 0 for all sockets for which IPV6_AUTOFLOWLABEL is
      not explicitly enabled.  Fix it to return the effective value, whether
      that has been set at the socket or net namespace level.
      
      Fixes: 513674b5
      
       ("net: reevalulate autoflowlabel setting after sysctl ...")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b0d3e81
    • Alexey Kodanev's avatar
      dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state · 5bb5ae97
      Alexey Kodanev authored
      
      [ Upstream commit dd5684ec ]
      
      ccid2_hc_tx_rto_expire() timer callback always restarts the timer
      again and can run indefinitely (unless it is stopped outside), and after
      commit 120e9dab ("dccp: defer ccid_hc_tx_delete() at dismantle time"),
      which moved ccid_hc_tx_delete() (also includes sk_stop_timer()) from
      dccp_destroy_sock() to sk_destruct(), this started to happen quite often.
      The timer prevents releasing the socket, as a result, sk_destruct() won't
      be called.
      
      Found with LTP/dccp_ipsec tests running on the bonding device,
      which later couldn't be unloaded after the tests were completed:
      
        unregister_netdevice: waiting for bond0 to become free. Usage count = 148
      
      Fixes: 2a91aa39
      
       ("[DCCP] CCID2: Initial CCID2 (TCP-Like) implementation")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bb5ae97
    • Greg KH's avatar
      eventpoll.h: add missing epoll event masks · 5f6c581b
      Greg KH authored
      commit 7e040726
      
       upstream.
      
      [resend due to me forgetting to cc: linux-api the first time around I
      posted these back on Feb 23]
      
      From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      For some reason these values are not in the uapi header file, so any
      libc has to define it themselves.  To prevent them from needing to do
      this, just have the kernel provide the correct values.
      Reported-by: default avatarElliott Hughes <enh@google.com>
      Signed-off-by: default avatarGreg Hackmann <ghackmann@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f6c581b
    • Ben Hutchings's avatar
      vsyscall: Fix permissions for emulate mode with KAISER/PTI · 9a0be5af
      Ben Hutchings authored
      
      
      The backport of KAISER to 4.4 turned vsyscall emulate mode into native
      mode.  Add a vsyscall_pgprot variable to hold the correct page
      protections, like Borislav and Hugh did for 3.2 and 3.18.
      
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      9a0be5af
    • Thomas Meyer's avatar
      um: link vmlinux with -no-pie · 1be7d46e
      Thomas Meyer authored
      commit 883354af
      
       upstream.
      
      Debian's gcc defaults to pie. The global Makefile already defines the -fno-pie option.
      Link UML dynamic kernel image also with -no-pie to fix the build.
      Signed-off-by: default avatarThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Cc: Bernie Innocenti <codewiz@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1be7d46e
    • Martin Brandenburg's avatar
      orangefs: fix deadlock; do not write i_size in read_iter · d680db72
      Martin Brandenburg authored
      commit 6793f1c4 upstream.
      
      After do_readv_writev, the inode cache is invalidated anyway, so i_size
      will never be read.  It will be fetched from the server which will also
      know about updates from other machines.
      
      Fixes deadlock on 32-bit SMP.
      
      See https://marc.info/?l=linux-fsdevel&m=151268557427760&w=2
      
      Signed-off-by: default avatarMartin Brandenburg <martin@omnibond.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Mike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d680db72
    • Aaron Ma's avatar
      Input: trackpoint - force 3 buttons if 0 button is reported · 42f0aba5
      Aaron Ma authored
      commit f5d07b9e
      
       upstream.
      
      Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands.
      They supposed to reply with 0x02, 0x03, or 0x04 in response to the
      "Read Extended ID" command, so we would know not to try certain extended
      commands. Unfortunately even some trackpoints reporting the original IBM
      version (0x01 firmware 0x0e) now respond with incorrect data to the "Get
      Extended Buttons" command:
      
       thinkpad_acpi: ThinkPad BIOS R0DET87W (1.87 ), EC unknown
       thinkpad_acpi: Lenovo ThinkPad E470, model 20H1004SGE
      
       psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 0/0
      
      Since there are no trackpoints without buttons, let's assume the trackpoint
      has 3 buttons when we get 0 response to the extended buttons query.
      Signed-off-by: default avatarAaron Ma <aaron.ma@canonical.com>
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196253
      
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f0aba5
    • Johannes Weiner's avatar
      mm: fix 100% CPU kswapd busyloop on unreclaimable nodes · 19a7db1e
      Johannes Weiner authored
      commit c73322d0 upstream.
      
      Patch series "mm: kswapd spinning on unreclaimable nodes - fixes and
      cleanups".
      
      Jia reported a scenario in which the kswapd of a node indefinitely spins
      at 100% CPU usage.  We have seen similar cases at Facebook.
      
      The kernel's current method of judging its ability to reclaim a node (or
      whether to back off and sleep) is based on the amount of scanned pages
      in proportion to the amount of reclaimable pages.  In Jia's and our
      scenarios, there are no reclaimable pages in the node, however, and the
      condition for backing off is never met.  Kswapd busyloops in an attempt
      to restore the watermarks while having nothing to work with.
      
      This series reworks the definition of an unreclaimable node based not on
      scanning but on whether kswapd is able to actually reclaim pages in
      MAX_RECLAIM_RETRIES (16) consecutive runs.  This is the same criteria
      the page allocator uses for giving up on direct reclaim and invoking the
      OOM killer.  If it cannot free any pages, kswapd will go to sleep and
      leave further attempts to direct reclaim invocations, which will either
      make progress and re-enable kswapd, or invoke the OOM killer.
      
      Patch #1 fixes the immediate problem Jia reported, the remainder are
      smaller fixlets, cleanups, and overall phasing out of the old method.
      
      Patch #6 is the odd one out.  It's a nice cleanup to get_scan_count(),
      and directly related to #5, but in itself not relevant to the series.
      
      If the whole series is too ambitious for 4.11, I would consider the
      first three patches fixes, the rest cleanups.
      
      This patch (of 9):
      
      Jia He reports a problem with kswapd spinning at 100% CPU when
      requesting more hugepages than memory available in the system:
      
      $ echo 4000 >/proc/sys/vm/nr_hugepages
      
      top - 13:42:59 up  3:37,  1 user,  load average: 1.09, 1.03, 1.01
      Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
      %Cpu(s):  0.0 us, 12.5 sy,  0.0 ni, 85.5 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
      KiB Mem:  31371520 total, 30915136 used,   456384 free,      320 buffers
      KiB Swap:  6284224 total,   115712 used,  6168512 free.    48192 cached Mem
      
        PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
         76 root      20   0       0      0      0 R 100.0 0.000 217:17.29 kswapd3
      
      At that time, there are no reclaimable pages left in the node, but as
      kswapd fails to restore the high watermarks it refuses to go to sleep.
      
      Kswapd needs to back away from nodes that fail to balance.  Up until
      commit 1d82de61 ("mm, vmscan: make kswapd reclaim in terms of
      nodes") kswapd had such a mechanism.  It considered zones whose
      theoretically reclaimable pages it had reclaimed six times over as
      unreclaimable and backed away from them.  This guard was erroneously
      removed as the patch changed the definition of a balanced node.
      
      However, simply restoring this code wouldn't help in the case reported
      here: there *are* no reclaimable pages that could be scanned until the
      threshold is met.  Kswapd would stay awake anyway.
      
      Introduce a new and much simpler way of backing off.  If kswapd runs
      through MAX_RECLAIM_RETRIES (16) cycles without reclaiming a single
      page, make it back off from the node.  This is the same number of shots
      direct reclaim takes before declaring OOM.  Kswapd will go to sleep on
      that node until a direct reclaimer manages to reclaim some pages, thus
      proving the node reclaimable again.
      
      [hannes@cmpxchg.org: check kswapd failure against the cumulative nr_reclaimed count]
        Link: http://lkml.kernel.org/r/20170306162410.GB2090@cmpxchg.org
      [shakeelb@google.com: fix condition for throttle_direct_reclaim]
        Link: http://lkml.kernel.org/r/20170314183228.20152-1-shakeelb@google.com
      Link: http://lkml.kernel.org/r/20170228214007.5621-2-hannes@cmpxchg.org
      
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
      Reported-by: default avatarJia He <hejianet@gmail.com>
      Tested-by: default avatarJia He <hejianet@gmail.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarHillf Danton <hillf.zj@alibaba-inc.com>
      Acked-by: default avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Dmitry Shmidt <dimitrysh@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19a7db1e
    • Greg Kroah-Hartman's avatar
      Revert "module: Add retpoline tag to VERMAGIC" · e62b0c66
      Greg Kroah-Hartman authored
      commit 5132ede0 upstream.
      
      This reverts commit 6cfb521a
      
      .
      
      Turns out distros do not want to make retpoline as part of their "ABI",
      so this patch should not have been merged.  Sorry Andi, this was my
      fault, I suggested it when your original patch was the "correct" way of
      doing this instead.
      Reported-by: default avatarJiri Kosina <jikos@kernel.org>
      Fixes: 6cfb521a
      
       ("module: Add retpoline tag to VERMAGIC")
      Acked-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: rusty@rustcorp.com.au
      Cc: arjan.van.de.ven@intel.com
      Cc: jeyu@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e62b0c66
    • Johannes Thumshirn's avatar
      scsi: libiscsi: fix shifting of DID_REQUEUE host byte · c41bb027
      Johannes Thumshirn authored
      commit eef9ffdf
      
       upstream.
      
      The SCSI host byte should be shifted left by 16 in order to have
      scsi_decide_disposition() do the right thing (.i.e. requeue the
      command).
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Fixes: 661134ad
      
       ("[SCSI] libiscsi, bnx2i: make bound ep check common")
      Cc: Lee Duncan <lduncan@suse.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>
      Cc: Chris Leech <cleech@redhat.com>
      Acked-by: default avatarLee Duncan <lduncan@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c41bb027
    • Jiri Slaby's avatar
      fs/fcntl: f_setown, avoid undefined behaviour · 7b50205c
      Jiri Slaby authored
      commit fc3dc674 upstream.
      
      fcntl(0, F_SETOWN, 0x80000000) triggers:
      UBSAN: Undefined behaviour in fs/fcntl.c:118:7
      negation of -2147483648 cannot be represented in type 'int':
      CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
      ...
      Call Trace:
      ...
       [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200
       [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30
       [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1
      
      Fix that by checking the arg parameter properly (against INT_MAX) before
      "who = -who". And return immediatelly with -EINVAL in case it is wrong.
      Note that according to POSIX we can return EINVAL:
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
      
      
      
          [EINVAL]
              The cmd argument is F_SETOWN and the value of the argument
              is not valid as a process or process group identifier.
      
      [v2] returns an error, v1 used to fail silently
      [v3] implement proper check for the bad value INT_MIN
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jeff Layton <jlayton@poochiereds.net>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b50205c
    • Jeff Mahoney's avatar
      reiserfs: don't preallocate blocks for extended attributes · 0ccfbd4d
      Jeff Mahoney authored
      commit 54930dfe
      
       upstream.
      
      Most extended attributes will fit in a single block.  More importantly,
      we drop the reference to the inode while holding the transaction open
      so the preallocated blocks aren't released.  As a result, the inode
      may be evicted before it's removed from the transaction's prealloc list
      which can cause memory corruption.
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ccfbd4d
    • Jeff Mahoney's avatar
      reiserfs: fix race in prealloc discard · b7d25282
      Jeff Mahoney authored
      commit 08db141b
      
       upstream.
      
      The main loop in __discard_prealloc is protected by the reiserfs write lock
      which is dropped across schedules like the BKL it replaced.  The problem is
      that it checks the value, calls a routine that schedules, and then adjusts
      the state.  As a result, two threads that are calling
      reiserfs_prealloc_discard at the same time can race when one calls
      reiserfs_free_prealloc_block, the lock is dropped, and the other calls
      reiserfs_free_prealloc_block with the same block number.  In the right
      circumstances, it can cause the prealloc count to go negative.
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7d25282