1. 29 Apr, 2018 40 commits
    • Jann Horn's avatar
      tcp: don't read out-of-bounds opsize · f8382596
      Jann Horn authored
      [ Upstream commit 7e5a206a ]
      
      The old code reads the "opsize" variable from out-of-bounds memory (first
      byte behind the segment) if a broken TCP segment ends directly after an
      opcode that is neither EOL nor NOP.
      
      The result of the read isn't used for anything, so the worst thing that
      could theoretically happen is a pagefault; and since the physmap is usually
      mostly contiguous, even that seems pretty unlikely.
      
      The following C reproducer triggers the uninitialized read - however, you
      can't actually see anything happen unless you put something like a
      pr_warn() in tcp_parse_md5sig_option() to print the opsize.
      
      ====================================
      #define _GNU_SOURCE
      #include <arpa/inet.h>
      #include <stdlib.h>
      #include <errno.h>
      #include <stdarg.h>
      #include <net/if.h>
      #include <linux/if.h>
      #include <linux/ip.h>
      #include <linux/tcp.h>
      #include <linux/in.h>
      #include <linux/if_tun.h>
      #include <err.h>
      #include <sys/types.h>
      #include <sys/stat.h>
      #include <fcntl.h>
      #include <string.h>
      #include <stdio.h>
      #include <unistd.h>
      #include <sys/ioctl.h>
      #include <assert.h>
      
      void systemf(const char *command, ...) {
        char *full_command;
        va_list ap;
        va_start(ap, command);
        if (vasprintf(&full_command, command, ap) == -1)
          err(1, "vasprintf");
        va_end(ap);
        printf("systemf: <<<%s>>>\n", full_command);
        system(full_command);
      }
      
      char *devname;
      
      int tun_alloc(char *name) {
        int fd = open("/dev/net/tun", O_RDWR);
        if (fd == -1)
          err(1, "open tun dev");
        static struct ifreq req = { .ifr_flags = IFF_TUN|IFF_NO_PI };
        strcpy(req.ifr_name, name);
        if (ioctl(fd, TUNSETIFF, &req))
          err(1, "TUNSETIFF");
        devname = req.ifr_name;
        printf("device name: %s\n", devname);
        return fd;
      }
      
      #define IPADDR(a,b,c,d) (((a)<<0)+((b)<<8)+((c)<<16)+((d)<<24))
      
      void sum_accumulate(unsigned int *sum, void *data, int len) {
        assert((len&2)==0);
        for (int i=0; i<len/2; i++) {
          *sum += ntohs(((unsigned short *)data)[i]);
        }
      }
      
      unsigned short sum_final(unsigned int sum) {
        sum = (sum >> 16) + (sum & 0xffff);
        sum = (sum >> 16) + (sum & 0xffff);
        return htons(~sum);
      }
      
      void fix_ip_sum(struct iphdr *ip) {
        unsigned int sum = 0;
        sum_accumulate(&sum, ip, sizeof(*ip));
        ip->check = sum_final(sum);
      }
      
      void fix_tcp_sum(struct iphdr *ip, struct tcphdr *tcp) {
        unsigned int sum = 0;
        struct {
          unsigned int saddr;
          unsigned int daddr;
          unsigned char pad;
          unsigned char proto_num;
          unsigned short tcp_len;
        } fakehdr = {
          .saddr = ip->saddr,
          .daddr = ip->daddr,
          .proto_num = ip->protocol,
          .tcp_len = htons(ntohs(ip->tot_len) - ip->ihl*4)
        };
        sum_accumulate(&sum, &fakehdr, sizeof(fakehdr));
        sum_accumulate(&sum, tcp, tcp->doff*4);
        tcp->check = sum_final(sum);
      }
      
      int main(void) {
        int tun_fd = tun_alloc("inject_dev%d");
        systemf("ip link set %s up", devname);
        systemf("ip addr add 192.168.42.1/24 dev %s", devname);
      
        struct {
          struct iphdr ip;
          struct tcphdr tcp;
          unsigned char tcp_opts[20];
        } __attribute__((packed)) syn_packet = {
          .ip = {
            .ihl = sizeof(struct iphdr)/4,
            .version = 4,
            .tot_len = htons(sizeof(syn_packet)),
            .ttl = 30,
            .protocol = IPPROTO_TCP,
            /* FIXUP check */
            .saddr = IPADDR(192,168,42,2),
            .daddr = IPADDR(192,168,42,1)
          },
          .tcp = {
            .source = htons(1),
            .dest = htons(1337),
            .seq = 0x12345678,
            .doff = (sizeof(syn_packet.tcp)+sizeof(syn_packet.tcp_opts))/4,
            .syn = 1,
            .window = htons(64),
            .check = 0 /*FIXUP*/
          },
          .tcp_opts = {
            /* INVALID: trailing MD5SIG opcode after NOPs */
            1, 1, 1, 1, 1,
            1, 1, 1, 1, 1,
            1, 1, 1, 1, 1,
            1, 1, 1, 1, 19
          }
        };
        fix_ip_sum(&syn_packet.ip);
        fix_tcp_sum(&syn_packet.ip, &syn_packet.tcp);
        while (1) {
          int write_res = write(tun_fd, &syn_packet, sizeof(syn_packet));
          if (write_res != sizeof(syn_packet))
            err(1, "packet write failed");
        }
      }
      ====================================
      
      Fixes: cfb6eeb4 ("[TCP]: MD5 Signature Option (RFC2385) support.")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8382596
    • Cong Wang's avatar
      llc: delete timers synchronously in llc_sk_free() · e202fa9e
      Cong Wang authored
      [ Upstream commit b905ef9a ]
      
      The connection timers of an llc sock could be still flying
      after we delete them in llc_sk_free(), and even possibly
      after we free the sock. We could just wait synchronously
      here in case of troubles.
      
      Note, I leave other call paths as they are, since they may
      not have to wait, at least we can change them to synchronously
      when needed.
      
      Also, move the code to net/llc/llc_conn.c, which is apparently
      a better place.
      
      Reported-by: <syzbot+f922284c18ea23a8e457@syzkaller.appspotmail.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>
      e202fa9e
    • Eric Dumazet's avatar
      net: validate attribute sizes in neigh_dump_table() · 0e770d29
      Eric Dumazet authored
      [ Upstream commit 7dd07c14 ]
      
      Since neigh_dump_table() calls nlmsg_parse() without giving policy
      constraints, attributes can have arbirary size that we must validate
      
      Reported by syzbot/KMSAN :
      
      BUG: KMSAN: uninit-value in neigh_master_filtered net/core/neighbour.c:2292 [inline]
      BUG: KMSAN: uninit-value in neigh_dump_table net/core/neighbour.c:2348 [inline]
      BUG: KMSAN: uninit-value in neigh_dump_info+0x1af0/0x2250 net/core/neighbour.c:2438
      CPU: 1 PID: 3575 Comm: syzkaller268891 Not tainted 4.16.0+ #83
      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+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
       neigh_master_filtered net/core/neighbour.c:2292 [inline]
       neigh_dump_table net/core/neighbour.c:2348 [inline]
       neigh_dump_info+0x1af0/0x2250 net/core/neighbour.c:2438
       netlink_dump+0x9ad/0x1540 net/netlink/af_netlink.c:2225
       __netlink_dump_start+0x1167/0x12a0 net/netlink/af_netlink.c:2322
       netlink_dump_start include/linux/netlink.h:214 [inline]
       rtnetlink_rcv_msg+0x1435/0x1560 net/core/rtnetlink.c:4598
       netlink_rcv_skb+0x355/0x5f0 net/netlink/af_netlink.c:2447
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4653
       netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
       netlink_unicast+0x1672/0x1750 net/netlink/af_netlink.c:1337
       netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
       sock_sendmsg_nosec net/socket.c:630 [inline]
       sock_sendmsg net/socket.c:640 [inline]
       ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
       __sys_sendmsg net/socket.c:2080 [inline]
       SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
       SyS_sendmsg+0x54/0x80 net/socket.c:2087
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43fed9
      RSP: 002b:00007ffddbee2798 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fed9
      RDX: 0000000000000000 RSI: 0000000020005000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401800
      R13: 0000000000401890 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
       kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
       kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
       slab_post_alloc_hook mm/slab.h:445 [inline]
       slab_alloc_node mm/slub.c:2737 [inline]
       __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
       __kmalloc_reserve net/core/skbuff.c:138 [inline]
       __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
       alloc_skb include/linux/skbuff.h:984 [inline]
       netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
       netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
       sock_sendmsg_nosec net/socket.c:630 [inline]
       sock_sendmsg net/socket.c:640 [inline]
       ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
       __sys_sendmsg net/socket.c:2080 [inline]
       SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
       SyS_sendmsg+0x54/0x80 net/socket.c:2087
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 21fdd092 ("net: Add support for filtering neigh dump by master device")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e770d29
    • Guillaume Nault's avatar
      l2tp: check sockaddr length in pppol2tp_connect() · e9c46600
      Guillaume Nault authored
      [ Upstream commit eb1c28c0 ]
      
      Check sockaddr_len before dereferencing sp->sa_protocol, to ensure that
      it actually points to valid data.
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Reported-by: syzbot+a70ac890b23b1bf29f5c@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>
      e9c46600
    • Eric Biggers's avatar
      KEYS: DNS: limit the length of option strings · 06a02a81
      Eric Biggers authored
      [ Upstream commit 9c438d7a ]
      
      Adding a dns_resolver key whose payload contains a very long option name
      resulted in that string being printed in full.  This hit the WARN_ONCE()
      in set_precision() during the printk(), because printk() only supports a
      precision of up to 32767 bytes:
      
          precision 1000000 too large
          WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
      
      Fix it by limiting option strings (combined name + value) to a much more
      reasonable 128 bytes.  The exact limit is arbitrary, but currently the
      only recognized option is formatted as "dnserror=%lu" which fits well
      within this limit.
      
      Also ratelimit the printks.
      
      Reproducer:
      
          perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
      
      This bug was found using syzkaller.
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 4a2d7892 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06a02a81
    • Xin Long's avatar
      bonding: do not set slave_dev npinfo before slave_enable_netpoll in bond_enslave · a43e7cba
      Xin Long authored
      [ Upstream commit ddea788c ]
      
      After Commit 8a8efa22 ("bonding: sync netpoll code with bridge"), it
      would set slave_dev npinfo in slave_enable_netpoll when enslaving a dev
      if bond->dev->npinfo was set.
      
      However now slave_dev npinfo is set with bond->dev->npinfo before calling
      slave_enable_netpoll. With slave_dev npinfo set, __netpoll_setup called
      in slave_enable_netpoll will not call slave dev's .ndo_netpoll_setup().
      It causes that the lower dev of this slave dev can't set its npinfo.
      
      One way to reproduce it:
      
        # modprobe bonding
        # brctl addbr br0
        # brctl addif br0 eth1
        # ifconfig bond0 192.168.122.1/24 up
        # ifenslave bond0 eth2
        # systemctl restart netconsole
        # ifenslave bond0 br0
        # ifconfig eth2 down
        # systemctl restart netconsole
      
      The netpoll won't really work.
      
      This patch is to remove that slave_dev npinfo setting in bond_enslave().
      
      Fixes: 8a8efa22 ("bonding: sync netpoll code with bridge")
      Signed-off-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>
      a43e7cba
    • Martin Schwidefsky's avatar
      s390: correct module section names for expoline code revert · 037069f2
      Martin Schwidefsky authored
      [ Upstream commit 6cf09958 ]
      
      The main linker script vmlinux.lds.S for the kernel image merges
      the expoline code patch tables into two section ".nospec_call_table"
      and ".nospec_return_table". This is *not* done for the modules,
      there the sections retain their original names as generated by gcc:
      ".s390_indirect_call", ".s390_return_mem" and ".s390_return_reg".
      
      The module_finalize code has to check for the compiler generated
      section names, otherwise no code patching is done. This slows down
      the module code in case of "spectre_v2=off".
      
      Cc: stable@vger.kernel.org # 4.16
      Fixes: f19fbd5e ("s390: introduce execute-trampolines for branches")
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      037069f2
    • Martin Schwidefsky's avatar
      s390: correct nospec auto detection init order · 906cd975
      Martin Schwidefsky authored
      [ Upstream commit 6a3d1e81 ]
      
      With CONFIG_EXPOLINE_AUTO=y the call of spectre_v2_auto_early() via
      early_initcall is done *after* the early_param functions. This
      overwrites any settings done with the nobp/no_spectre_v2/spectre_v2
      parameters. The code patching for the kernel is done after the
      evaluation of the early parameters but before the early_initcall
      is done. The end result is a kernel image that is patched correctly
      but the kernel modules are not.
      
      Make sure that the nospec auto detection function is called before the
      early parameters are evaluated and before the code patching is done.
      
      Fixes: 6e179d64 ("s390: add automatic detection of the spectre defense")
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      906cd975
    • Martin Schwidefsky's avatar
      s390: add sysfs attributes for spectre · fa90b9a2
      Martin Schwidefsky authored
      [ Upstream commit d424986f ]
      
      Set CONFIG_GENERIC_CPU_VULNERABILITIES and provide the two functions
      cpu_show_spectre_v1 and cpu_show_spectre_v2 to report the spectre
      mitigations.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa90b9a2
    • Martin Schwidefsky's avatar
      s390: report spectre mitigation via syslog · 4a51204f
      Martin Schwidefsky authored
      [ Upstream commit bc035599 ]
      
      Add a boot message if either of the spectre defenses is active.
      The message is
          "Spectre V2 mitigation: execute trampolines."
      or  "Spectre V2 mitigation: limited branch prediction."
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a51204f
    • Martin Schwidefsky's avatar
      s390: add automatic detection of the spectre defense · 3e17958c
      Martin Schwidefsky authored
      [ Upstream commit 6e179d64 ]
      
      Automatically decide between nobp vs. expolines if the spectre_v2=auto
      kernel parameter is specified or CONFIG_EXPOLINE_AUTO=y is set.
      
      The decision made at boot time due to CONFIG_EXPOLINE_AUTO=y being set
      can be overruled with the nobp, nospec and spectre_v2 kernel parameters.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e17958c
    • Martin Schwidefsky's avatar
      s390: move nobp parameter functions to nospec-branch.c · 2afb4e9d
      Martin Schwidefsky authored
      [ Upstream commit b2e2f43a ]
      
      Keep the code for the nobp parameter handling with the code for
      expolines. Both are related to the spectre v2 mitigation.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2afb4e9d
    • Christian Borntraeger's avatar
      s390/entry.S: fix spurious zeroing of r0 · 7634817f
      Christian Borntraeger authored
      [ Upstream commit d3f46896 ]
      
      when a system call is interrupted we might call the critical section
      cleanup handler that re-does some of the operations. When we are between
      .Lsysc_vtime and .Lsysc_do_svc we might also redo the saving of the
      problem state registers r0-r7:
      
      .Lcleanup_system_call:
      [...]
      0:      # update accounting time stamp
              mvc     __LC_LAST_UPDATE_TIMER(8),__LC_SYNC_ENTER_TIMER
              # set up saved register r11
              lg      %r15,__LC_KERNEL_STACK
              la      %r9,STACK_FRAME_OVERHEAD(%r15)
              stg     %r9,24(%r11)            # r11 pt_regs pointer
              # fill pt_regs
              mvc     __PT_R8(64,%r9),__LC_SAVE_AREA_SYNC
      --->    stmg    %r0,%r7,__PT_R0(%r9)
      
      The problem is now, that we might have already zeroed out r0.
      The fix is to move the zeroing of r0 after sysc_do_svc.
      Reported-by: default avatarFarhan Ali <alifm@linux.vnet.ibm.com>
      Fixes: 7041d281 ("s390: scrub registers on kernel entry and KVM exit")
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7634817f
    • Martin Schwidefsky's avatar
      s390: do not bypass BPENTER for interrupt system calls · 7ae60d00
      Martin Schwidefsky authored
      [ Upstream commit d5feec04 ]
      
      The system call path can be interrupted before the switch back to the
      standard branch prediction with BPENTER has been done. The critical
      section cleanup code skips forward to .Lsysc_do_svc and bypasses the
      BPENTER. In this case the kernel and all subsequent code will run with
      the limited branch prediction.
      
      Fixes: eacf67eb9b32 ("s390: run user space and KVM guests with modified branch prediction")
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ae60d00
    • Eugeniu Rosca's avatar
      s390: Replace IS_ENABLED(EXPOLINE_*) with IS_ENABLED(CONFIG_EXPOLINE_*) · 49a48a0e
      Eugeniu Rosca authored
      [ Upstream commit 2cb370d6 ]
      
      I've accidentally stumbled upon the IS_ENABLED(EXPOLINE_*) lines, which
      obviously always evaluate to false. Fix this.
      
      Fixes: f19fbd5e ("s390: introduce execute-trampolines for branches")
      Signed-off-by: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49a48a0e
    • Christian Borntraeger's avatar
      KVM: s390: force bp isolation for VSIE · 2a0b0e13
      Christian Borntraeger authored
      [ Upstream commit f315104a ]
      
      If the guest runs with bp isolation when doing a SIE instruction,
      we must also run the nested guest with bp isolation when emulating
      that SIE instruction.
      This is done by activating BPBC in the lpar, which acts as an override
      for lower level guests.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarJanosch Frank <frankja@linux.vnet.ibm.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a0b0e13
    • Martin Schwidefsky's avatar
      s390: introduce execute-trampolines for branches · 24fbc4ee
      Martin Schwidefsky authored
      [ Upstream commit f19fbd5e ]
      
      Add CONFIG_EXPOLINE to enable the use of the new -mindirect-branch= and
      -mfunction_return= compiler options to create a kernel fortified against
      the specte v2 attack.
      
      With CONFIG_EXPOLINE=y all indirect branches will be issued with an
      execute type instruction. For z10 or newer the EXRL instruction will
      be used, for older machines the EX instruction. The typical indirect
      call
      
      	basr	%r14,%r1
      
      is replaced with a PC relative call to a new thunk
      
      	brasl	%r14,__s390x_indirect_jump_r1
      
      The thunk contains the EXRL/EX instruction to the indirect branch
      
      __s390x_indirect_jump_r1:
      	exrl	0,0f
      	j	.
      0:	br	%r1
      
      The detour via the execute type instruction has a performance impact.
      To get rid of the detour the new kernel parameter "nospectre_v2" and
      "spectre_v2=[on,off,auto]" can be used. If the parameter is specified
      the kernel and module code will be patched at runtime.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24fbc4ee
    • Martin Schwidefsky's avatar
      s390: run user space and KVM guests with modified branch prediction · a1f44e79
      Martin Schwidefsky authored
      [ Upstream commit 6b73044b ]
      
      Define TIF_ISOLATE_BP and TIF_ISOLATE_BP_GUEST and add the necessary
      plumbing in entry.S to be able to run user space and KVM guests with
      limited branch prediction.
      
      To switch a user space process to limited branch prediction the
      s390_isolate_bp() function has to be call, and to run a vCPU of a KVM
      guest associated with the current task with limited branch prediction
      call s390_isolate_bp_guest().
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1f44e79
    • Martin Schwidefsky's avatar
      s390: add options to change branch prediction behaviour for the kernel · 07f65a83
      Martin Schwidefsky authored
      [ Upstream commit d768bd89 ]
      
      Add the PPA instruction to the system entry and exit path to switch
      the kernel to a different branch prediction behaviour. The instructions
      are added via CPU alternatives and can be disabled with the "nospec"
      or the "nobp=0" kernel parameter. If the default behaviour selected
      with CONFIG_KERNEL_NOBP is set to "n" then the "nobp=1" parameter can be
      used to enable the changed kernel branch prediction.
      Acked-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07f65a83
    • Martin Schwidefsky's avatar
      s390/alternative: use a copy of the facility bit mask · 46bd2c0f
      Martin Schwidefsky authored
      [ Upstream commit cf148998 ]
      
      To be able to switch off specific CPU alternatives with kernel parameters
      make a copy of the facility bit mask provided by STFLE and use the copy
      for the decision to apply an alternative.
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46bd2c0f
    • Martin Schwidefsky's avatar
      s390: add optimized array_index_mask_nospec · 2dcf46aa
      Martin Schwidefsky authored
      [ Upstream commit e2dd8333 ]
      
      Add an optimized version of the array_index_mask_nospec function for
      s390 based on a compare and a subtract with borrow.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2dcf46aa
    • Martin Schwidefsky's avatar
      s390: scrub registers on kernel entry and KVM exit · c225febe
      Martin Schwidefsky authored
      [ Upstream commit 7041d281 ]
      
      Clear all user space registers on entry to the kernel and all KVM guest
      registers on KVM guest exit if the register does not contain either a
      parameter or a result value.
      Reviewed-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c225febe
    • Christian Borntraeger's avatar
      KVM: s390: wire up bpb feature · 4d9c2b61
      Christian Borntraeger authored
      [ Upstream commit 35b3fde6 ]
      
      The new firmware interfaces for branch prediction behaviour changes
      are transparently available for the guest. Nevertheless, there is
      new state attached that should be migrated and properly resetted.
      Provide a mechanism for handling reset, migration and VSIE.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      [Changed capability number to 152. - Radim]
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d9c2b61
    • Heiko Carstens's avatar
      s390: enable CPU alternatives unconditionally · 420fd816
      Heiko Carstens authored
      [ Upstream commit 049a2c2d ]
      
      Remove the CPU_ALTERNATIVES config option and enable the code
      unconditionally. The config option was only added to avoid a conflict
      with the named saved segment support. Since that code is gone there is
      no reason to keep the CPU_ALTERNATIVES config option.
      
      Just enable it unconditionally to also reduce the number of config
      options and make it less likely that something breaks.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      420fd816
    • Vasily Gorbik's avatar
      s390: introduce CPU alternatives · d69aa5e6
      Vasily Gorbik authored
      [ Upstream commit 686140a1 ]
      
      Implement CPU alternatives, which allows to optionally patch newer
      instructions at runtime, based on CPU facilities availability.
      
      A new kernel boot parameter "noaltinstr" disables patching.
      
      Current implementation is derived from x86 alternatives. Although
      ideal instructions padding (when altinstr is longer then oldinstr)
      is added at compile time, and no oldinstr nops optimization has to be
      done at runtime. Also couple of compile time sanity checks are done:
      1. oldinstr and altinstr must be <= 254 bytes long,
      2. oldinstr and altinstr must not have an odd length.
      
      alternative(oldinstr, altinstr, facility);
      alternative_2(oldinstr, altinstr1, facility1, altinstr2, facility2);
      
      Both compile time and runtime padding consists of either 6/4/2 bytes nop
      or a jump (brcl) + 2 bytes nop filler if padding is longer then 6 bytes.
      
      .altinstructions and .altinstr_replacement sections are part of
      __init_begin : __init_end region and are freed after initialization.
      Signed-off-by: default avatarVasily Gorbik <gor@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d69aa5e6
    • Sinan Kaya's avatar
      PCI: Wait up to 60 seconds for device to become ready after FLR · c8b1584e
      Sinan Kaya authored
      commit 821cdad5 upstream.
      
      Sporadic reset issues have been observed with an Intel 750 NVMe drive while
      assigning the physical function to the guest machine.  The sequence of
      events observed is as follows:
      
        - perform a Function Level Reset (FLR)
        - sleep up to 1000ms total
        - read ~0 from PCI_COMMAND (CRS completion for config read)
        - warn that the device didn't return from FLR
        - touch the device before it's ready
        - device drops config writes when we restore register settings (there's
          no mechanism for software to learn about CRS completions for writes)
        - incomplete register restore leaves device in inconsistent state
        - device probe fails because device is in inconsistent state
      
      After reset, an endpoint may respond to config requests with Configuration
      Request Retry Status (CRS) to indicate that it is not ready to accept new
      requests. See PCIe r3.1, sec 2.3.1 and 6.6.2.
      
      Increase the timeout value from 1 second to 60 seconds to cover the period
      where device responds with CRS and also report polling progress.
      Signed-off-by: default avatarSinan Kaya <okaya@codeaurora.org>
      [bhelgaas: include the mandatory 100ms in the delays we print]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8b1584e
    • Karthikeyan Periyasamy's avatar
      Revert "ath10k: send (re)assoc peer command when NSS changed" · 237b5a36
      Karthikeyan Periyasamy authored
      commit 55cc11da upstream.
      
      This reverts commit 55884c04.
      
      When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
      (Operating Mode Notification for the NSS change) periodically to AP this causes
      ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
      NSS update. Over the time (with a certain client it can happen within 15 mins
      when there are over 500 of these VHT action frames) continuous calls of
      WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.
      
      To my knowledge setting WMI_PEER_NSS peer param itself enough to handle NSS
      updates and no need to call ath10k_station_assoc(). So revert the original
      commit from 2014 as it's unclear why the change was really needed.
      Now the firmware assert doesn't happen anymore.
      
      Issue observed in QCA9984 platform with firmware version:10.4-3.5.3-00053.
      This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 and
      QCA988x platform with firmware version: 10.2.4-1.0-00036.
      
      Firmware Assert log:
      
      ath10k_pci 0002:01:00.0: firmware crashed! (guid e61f1274-9acd-4c5b-bcca-e032ea6e723c)
      ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
      ath10k_pci 0002:01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
      ath10k_pci 0002:01:00.0: firmware ver 10.4-3.5.3-00053 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 4c56a386
      ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:4 crc32 c2271344
      ath10k_pci 0002:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
      ath10k_pci 0002:01:00.0: firmware register dump:
      ath10k_pci 0002:01:00.0: [00]: 0x0000000A 0x000015B3 0x00981E5F 0x00975B31
      ath10k_pci 0002:01:00.0: [04]: 0x00981E5F 0x00060530 0x00000011 0x00446C60
      ath10k_pci 0002:01:00.0: [08]: 0x0042F1FC 0x00458080 0x00000017 0x00000000
      ath10k_pci 0002:01:00.0: [12]: 0x00000009 0x00000000 0x00973ABC 0x00973AD2
      ath10k_pci 0002:01:00.0: [16]: 0x00973AB0 0x00960E62 0x009606CA 0x00000000
      ath10k_pci 0002:01:00.0: [20]: 0x40981E5F 0x004066DC 0x00400000 0x00981E34
      ath10k_pci 0002:01:00.0: [24]: 0x80983B48 0x0040673C 0x000000C0 0xC0981E5F
      ath10k_pci 0002:01:00.0: [28]: 0x80993DEB 0x0040676C 0x00431AB8 0x0045D0C4
      ath10k_pci 0002:01:00.0: [32]: 0x80993E5C 0x004067AC 0x004303C0 0x0045D0C4
      ath10k_pci 0002:01:00.0: [36]: 0x80994AAB 0x004067DC 0x00000000 0x0045D0C4
      ath10k_pci 0002:01:00.0: [40]: 0x809971A0 0x0040681C 0x004303C0 0x00441B00
      ath10k_pci 0002:01:00.0: [44]: 0x80991904 0x0040688C 0x004303C0 0x0045D0C4
      ath10k_pci 0002:01:00.0: [48]: 0x80963AD3 0x00406A7C 0x004303C0 0x009918FC
      ath10k_pci 0002:01:00.0: [52]: 0x80960E80 0x00406A9C 0x0000001F 0x00400000
      ath10k_pci 0002:01:00.0: [56]: 0x80960E51 0x00406ACC 0x00400000 0x00000000
      ath10k_pci 0002:01:00.0: Copy Engine register dump:
      ath10k_pci 0002:01:00.0: index: addr: sr_wr_idx: sr_r_idx: dst_wr_idx: dst_r_idx:
      ath10k_pci 0002:01:00.0: [00]: 0x0004a000 15 15 3 3
      ath10k_pci 0002:01:00.0: [01]: 0x0004a400 17 17 212 213
      ath10k_pci 0002:01:00.0: [02]: 0x0004a800 21 21 20 21
      ath10k_pci 0002:01:00.0: [03]: 0x0004ac00 25 25 27 25
      ath10k_pci 0002:01:00.0: [04]: 0x0004b000 515 515 144 104
      ath10k_pci 0002:01:00.0: [05]: 0x0004b400 28 28 155 156
      ath10k_pci 0002:01:00.0: [06]: 0x0004b800 12 12 12 12
      ath10k_pci 0002:01:00.0: [07]: 0x0004bc00 1 1 1 1
      ath10k_pci 0002:01:00.0: [08]: 0x0004c000 0 0 127 0
      ath10k_pci 0002:01:00.0: [09]: 0x0004c400 1 1 1 1
      ath10k_pci 0002:01:00.0: [10]: 0x0004c800 0 0 0 0
      ath10k_pci 0002:01:00.0: [11]: 0x0004cc00 0 0 0 0
      ath10k_pci 0002:01:00.0: CE[1] write_index 212 sw_index 213 hw_index 0 nentries_mask 0x000001ff
      ath10k_pci 0002:01:00.0: CE[2] write_index 20 sw_index 21 hw_index 0 nentries_mask 0x0000007f
      ath10k_pci 0002:01:00.0: CE[5] write_index 155 sw_index 156 hw_index 0 nentries_mask 0x000001ff
      ath10k_pci 0002:01:00.0: DMA addr: nbytes: meta data: byte swap: gather:
      ath10k_pci 0002:01:00.0: [455]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [456]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [457]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [458]: 0x594a0038 0 0 0 1
      ath10k_pci 0002:01:00.0: [459]: 0x580c0a42 0 0 0 0
      ath10k_pci 0002:01:00.0: [460]: 0x594a0060 0 0 0 1
      ath10k_pci 0002:01:00.0: [461]: 0x580c0c42 0 0 0 0
      ath10k_pci 0002:01:00.0: [462]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [463]: 0x580c0c42 0 0 0 0
      ath10k_pci 0002:01:00.0: [464]: 0x594a0038 0 0 0 1
      ath10k_pci 0002:01:00.0: [465]: 0x580c0a42 0 0 0 0
      ath10k_pci 0002:01:00.0: [466]: 0x594a0060 0 0 0 1
      ath10k_pci 0002:01:00.0: [467]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [468]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [469]: 0x580c1c42 0 0 0 0
      ath10k_pci 0002:01:00.0: [470]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [471]: 0x580c1c42 0 0 0 0
      ath10k_pci 0002:01:00.0: [472]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [473]: 0x580c1c42 0 0 0 0
      ath10k_pci 0002:01:00.0: [474]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [475]: 0x580c0642 0 0 0 0
      ath10k_pci 0002:01:00.0: [476]: 0x594a0038 0 0 0 1
      ath10k_pci 0002:01:00.0: [477]: 0x580c0842 0 0 0 0
      ath10k_pci 0002:01:00.0: [478]: 0x594a0060 0 0 0 1
      ath10k_pci 0002:01:00.0: [479]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [480]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [481]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [482]: 0x594a0038 0 0 0 1
      ath10k_pci 0002:01:00.0: [483]: 0x580c0842 0 0 0 0
      ath10k_pci 0002:01:00.0: [484]: 0x594a0060 0 0 0 1
      ath10k_pci 0002:01:00.0: [485]: 0x580c0642 0 0 0 0
      ath10k_pci 0002:01:00.0: [486]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [487]: 0x580c0642 0 0 0 0
      ath10k_pci 0002:01:00.0: [488]: 0x594a0038 0 0 0 1
      ath10k_pci 0002:01:00.0: [489]: 0x580c0842 0 0 0 0
      ath10k_pci 0002:01:00.0: [490]: 0x594a0060 0 0 0 1
      ath10k_pci 0002:01:00.0: [491]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [492]: 0x58174040 0 1 0 0
      ath10k_pci 0002:01:00.0: [493]: 0x5a946040 0 1 0 0
      ath10k_pci 0002:01:00.0: [494]: 0x59909040 0 1 0 0
      ath10k_pci 0002:01:00.0: [495]: 0x5ae5a040 0 1 0 0
      ath10k_pci 0002:01:00.0: [496]: 0x58096040 0 1 0 0
      ath10k_pci 0002:01:00.0: [497]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [498]: 0x580c0642 0 0 0 0
      ath10k_pci 0002:01:00.0: [499]: 0x5c1e0040 0 1 0 0
      ath10k_pci 0002:01:00.0: [500]: 0x58153040 0 1 0 0
      ath10k_pci 0002:01:00.0: [501]: 0x58129040 0 1 0 0
      ath10k_pci 0002:01:00.0: [502]: 0x5952f040 0 1 0 0
      ath10k_pci 0002:01:00.0: [503]: 0x59535040 0 1 0 0
      ath10k_pci 0002:01:00.0: [504]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [505]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [506]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [507]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [508]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [509]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [510]: 0x594a0010 0 0 0 1
      ath10k_pci 0002:01:00.0: [511]: 0x580c0042 0 0 0 0
      ath10k_pci 0002:01:00.0: [512]: 0x5adcc040 0 1 0 0
      ath10k_pci 0002:01:00.0: [513]: 0x5cf3d040 0 1 0 0
      ath10k_pci 0002:01:00.0: [514]: 0x5c1e9040 64 1 0 0
      ath10k_pci 0002:01:00.0: [515]: 0x00000000 0 0 0 0
      Signed-off-by: default avatarKarthikeyan Periyasamy <periyasa@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      237b5a36
    • Greg Kroah-Hartman's avatar
      Revert "pinctrl: intel: Initialize GPIO properly when used through irqchip" · b5145685
      Greg Kroah-Hartman authored
      This reverts commit f5a26acf
      
      Mike writes:
      	It seems that commit f5a26acf ("pinctrl: intel: Initialize GPIO
      	properly when used through irqchip") can cause problems on some Skylake
      	systems with Sunrisepoint PCH-H. Namely on certain systems it may turn
      	the backlight PWM pin from native mode to GPIO which makes the screen
      	blank during boot.
      
      	There is more information here:
      
      	  https://bugzilla.redhat.com/show_bug.cgi?id=1543769
      
      	The actual reason is that GPIO numbering used in BIOS is using "Windows"
      	numbers meaning that they don't match the hardware 1:1 and because of
      	this a wrong pin (backlight PWM) is picked and switched to GPIO mode.
      
      	There is a proper fix for this but since it has quite many dependencies
      	on commits that cannot be considered stable material, I suggest we
      	revert commit f5a26acf from stable trees 4.9, 4.14 and 4.15 to
      	prevent the backlight issue.
      Reported-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Fixes: f5a26acf ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
      Cc: Daniel Drake <drake@endlessm.com>
      Cc: Chris Chiu <chiu@endlessm.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5145685
    • Grant Grundler's avatar
      r8152: add Linksys USB3GIGV1 id · 403e7bd6
      Grant Grundler authored
      commit 90841047 upstream.
      
      This linksys dongle by default comes up in cdc_ether mode.
      This patch allows r8152 to claim the device:
         Bus 002 Device 002: ID 13b1:0041 Linksys
      Signed-off-by: default avatarGrant Grundler <grundler@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [krzk: Rebase on v4.4]
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      403e7bd6
    • Benjamin Beichler's avatar
      mac80211_hwsim: fix use-after-free bug in hwsim_exit_net · 21670a46
      Benjamin Beichler authored
      commit 8cfd36a0 upstream.
      
      When destroying a net namespace, all hwsim interfaces, which are not
      created in default namespace are deleted. But the async deletion of the
      interfaces could last longer than the actual destruction of the
      namespace, which results to an use after free bug. Therefore use
      synchronous deletion in this case.
      
      Fixes: 100cb9ff ("mac80211_hwsim: Allow managing radios from non-initial namespaces")
      Reported-by: syzbot+70ce058e01259de7bb1d@syzkaller.appspotmail.com
      Signed-off-by: default avatarBenjamin Beichler <benjamin.beichler@uni-rostock.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21670a46
    • Imre Deak's avatar
      drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing · 2d1264b5
      Imre Deak authored
      commit 5e1df40f upstream.
      
      Currently we see sporadic timeouts during CDCLK changing both on BXT and
      GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
      changing the frequency in a tight loop after blanking the display. The
      upper bound for the completion time is 800us based on my tests, so
      increase it from the current 500us to 2ms; with that I couldn't trigger
      the problem either on BXT or GLK.
      
      Note that timeouts happened during both the change notification and the
      voltage level setting PCODE request. (For the latter one BSpec doesn't
      require us to wait for completion before further HW programming.)
      
      This issue is similar to
      commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK
      change notification")
      but there the PCODE request does complete (as shown by the mbox
      busy flag), only the reply we get from PCODE indicates a failure.
      So there we keep resending the request until a success reply, here we
      just have to increase the timeout for the one PCODE request we send.
      
      v2:
      - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.9
      Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
      (cherry picked from commit e76019a8)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      (Rebased for v4.9 stable tree due to upstream intel_cdclk.c, cdclk_state and pcu_lock change)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d1264b5
    • Leon Romanovsky's avatar
      RDMA/mlx5: Fix NULL dereference while accessing XRC_TGT QPs · 9ffa6fb2
      Leon Romanovsky authored
      commit 75a45982 upstream.
      
      mlx5 modify_qp() relies on FW that the error will be thrown if wrong
      state is supplied. The missing check in FW causes the following crash
      while using XRC_TGT QPs.
      
      [   14.769632] BUG: unable to handle kernel NULL pointer dereference at (null)
      [   14.771085] IP: mlx5_ib_modify_qp+0xf60/0x13f0
      [   14.771894] PGD 800000001472e067 P4D 800000001472e067 PUD 14529067 PMD 0
      [   14.773126] Oops: 0002 [#1] SMP PTI
      [   14.773763] CPU: 0 PID: 365 Comm: ubsan Not tainted 4.16.0-rc1-00038-g8151138c0793 #119
      [   14.775192] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      [   14.777522] RIP: 0010:mlx5_ib_modify_qp+0xf60/0x13f0
      [   14.778417] RSP: 0018:ffffbf48001c7bd8 EFLAGS: 00010246
      [   14.779346] RAX: 0000000000000000 RBX: ffff9a8f9447d400 RCX: 0000000000000000
      [   14.780643] RDX: 0000000000000000 RSI: 000000000000000a RDI: 0000000000000000
      [   14.781930] RBP: 0000000000000000 R08: 00000000000217b0 R09: ffffffffbc9c1504
      [   14.783214] R10: fffff4a180519480 R11: ffff9a8f94523600 R12: ffff9a8f9493e240
      [   14.784507] R13: ffff9a8f9447d738 R14: 000000000000050a R15: 0000000000000000
      [   14.785800] FS:  00007f545b466700(0000) GS:ffff9a8f9fc00000(0000) knlGS:0000000000000000
      [   14.787073] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   14.787792] CR2: 0000000000000000 CR3: 00000000144be000 CR4: 00000000000006b0
      [   14.788689] Call Trace:
      [   14.789007]  _ib_modify_qp+0x71/0x120
      [   14.789475]  modify_qp.isra.20+0x207/0x2f0
      [   14.790010]  ib_uverbs_modify_qp+0x90/0xe0
      [   14.790532]  ib_uverbs_write+0x1d2/0x3c0
      [   14.791049]  ? __handle_mm_fault+0x93c/0xe40
      [   14.791644]  __vfs_write+0x36/0x180
      [   14.792096]  ? handle_mm_fault+0xc1/0x210
      [   14.792601]  vfs_write+0xad/0x1e0
      [   14.793018]  SyS_write+0x52/0xc0
      [   14.793422]  do_syscall_64+0x75/0x180
      [   14.793888]  entry_SYSCALL_64_after_hwframe+0x21/0x86
      [   14.794527] RIP: 0033:0x7f545ad76099
      [   14.794975] RSP: 002b:00007ffd78787468 EFLAGS: 00000287 ORIG_RAX: 0000000000000001
      [   14.795958] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f545ad76099
      [   14.797075] RDX: 0000000000000078 RSI: 0000000020009000 RDI: 0000000000000003
      [   14.798140] RBP: 00007ffd78787470 R08: 00007ffd78787480 R09: 00007ffd78787480
      [   14.799207] R10: 00007ffd78787480 R11: 0000000000000287 R12: 00005599ada98760
      [   14.800277] R13: 00007ffd78787560 R14: 0000000000000000 R15: 0000000000000000
      [   14.801341] Code: 4c 8b 1c 24 48 8b 83 70 02 00 00 48 c7 83 cc 02 00
      00 00 00 00 00 48 c7 83 24 03 00 00 00 00 00 00 c7 83 2c 03 00 00 00 00
      00 00 <c7> 00 00 00 00 00 48 8b 83 70 02 00 00 c7 40 04 00 00 00 00 4c
      [   14.804012] RIP: mlx5_ib_modify_qp+0xf60/0x13f0 RSP: ffffbf48001c7bd8
      [   14.804838] CR2: 0000000000000000
      [   14.805288] ---[ end trace 3f1da0df5c8b7c37 ]---
      
      Cc: syzkaller <syzkaller@googlegroups.com>
      Reported-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ffa6fb2
    • Jiri Olsa's avatar
      perf: Return proper values for user stack errors · 9acdfe4e
      Jiri Olsa authored
      commit 78b562fb upstream.
      
      Return immediately when we find issue in the user stack checks. The
      error value could get overwritten by following check for
      PERF_SAMPLE_REGS_INTR.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: syzkaller-bugs@googlegroups.com
      Cc: x86@kernel.org
      Fixes: 60e2364e ("perf: Add ability to sample machine state on interrupt")
      Link: http://lkml.kernel.org/r/20180415092352.12403-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9acdfe4e
    • Jiri Olsa's avatar
      perf: Fix sample_max_stack maximum check · ac6f0cb3
      Jiri Olsa authored
      commit 5af44ca5 upstream.
      
      The syzbot hit KASAN bug in perf_callchain_store having the entry stored
      behind the allocated bounds [1].
      
      We miss the sample_max_stack check for the initial event that allocates
      callchain buffers. This missing check allows to create an event with
      sample_max_stack value bigger than the global sysctl maximum:
      
        # sysctl -a | grep perf_event_max_stack
        kernel.perf_event_max_stack = 127
      
        # perf record -vv -C 1 -e cycles/max-stack=256/ kill
        ...
        perf_event_attr:
          size                             112
          ...
          sample_max_stack                 256
        ------------------------------------------------------------
        sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8 = 4
      
      Note the '-C 1', which forces perf record to create just single event.
      Otherwise it opens event for every cpu, then the sample_max_stack check
      fails on the second event and all's fine.
      
      The fix is to run the sample_max_stack check also for the first event
      with callchains.
      
      [1] https://marc.info/?l=linux-kernel&m=152352732920874&w=2
      
      Reported-by: syzbot+7c449856228b63ac951e@syzkaller.appspotmail.com
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: syzkaller-bugs@googlegroups.com
      Cc: x86@kernel.org
      Fixes: 97c79a38 ("perf core: Per event callchain limit")
      Link: http://lkml.kernel.org/r/20180415092352.12403-2-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac6f0cb3
    • Greg Kroah-Hartman's avatar
      Revert "perf tools: Decompress kernel module when reading DSO data" · fdc2090b
      Greg Kroah-Hartman authored
      This reverts commit e2d05499 which is
      commit 1d6b3c9b upstream.
      
      It breaks the build, so obviously none of us actually tested it :(
      Reported-by: default avatarMaxime Hadjinlian <maxime.hadjinlian@gmail.com>
      Reported-by: default avatarAkemi Yagi <toracat@elrepo.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: kernel-team@lge.com
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Sasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdc2090b
    • Sahitya Tummala's avatar
      jbd2: fix use after free in kjournald2() · cff3a5f2
      Sahitya Tummala authored
      commit dbfcef6b upstream.
      
      Below is the synchronization issue between unmount and kjournald2
      contexts, which results into use after free issue in kjournald2().
      Fix this issue by using journal->j_state_lock to synchronize the
      wait_event() done in journal_kill_thread() and the wake_up() done
      in kjournald2().
      
      TASK 1:
      umount cmd:
         |--jbd2_journal_destroy() {
             |--journal_kill_thread() {
                  write_lock(&journal->j_state_lock);
      	    journal->j_flags |= JBD2_UNMOUNT;
      	    ...
      	    write_unlock(&journal->j_state_lock);
      	    wake_up(&journal->j_wait_commit);	   TASK 2 wakes up here:
      	    					   kjournald2() {
      						     ...
      						     checks JBD2_UNMOUNT flag and calls goto end-loop;
      						     ...
      						     end_loop:
      						       write_unlock(&journal->j_state_lock);
      						       journal->j_task = NULL; --> If this thread gets
      						       pre-empted here, then TASK 1 wait_event will
      						       exit even before this thread is completely
      						       done.
      	    wait_event(journal->j_wait_done_commit, journal->j_task == NULL);
      	    ...
      	    write_lock(&journal->j_state_lock);
      	    write_unlock(&journal->j_state_lock);
      	  }
             |--kfree(journal);
           }
      }
      						       wake_up(&journal->j_wait_done_commit); --> this step
      						       now results into use after free issue.
      						   }
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cff3a5f2
    • Felix Fietkau's avatar
      ath9k_hw: check if the chip failed to wake up · ff738afb
      Felix Fietkau authored
      commit a34d0a0d upstream.
      
      In an RFC patch, Sven Eckelmann and Simon Wunderlich reported:
      
      "QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a
      state in which a read of AR_CFG always returns 0xdeadbeef.
      This should not happen when when the power_mode of the device is
      ATH9K_PM_AWAKE."
      
      Include the check for the default register state in the existing MAC
      hang check.
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff738afb
    • Paul Burton's avatar
      OF: Prevent unaligned access in of_alias_scan() · faf6fd75
      Paul Burton authored
      commit de96ec2a upstream.
      
      When allocating a struct alias_prop, of_alias_scan() only requested that
      it be aligned on a 4 byte boundary. The struct contains pointers which
      leads to us attempting 64 bit writes on 64 bit systems, and if the CPU
      doesn't support unaligned memory accesses then this causes problems -
      for example on some MIPS64r2 CPUs including the "mips64r2-generic" QEMU
      emulated CPU it will trigger an address error exception.
      
      Fix this by requesting alignment for the struct alias_prop allocation
      matching that which the compiler expects, using the __alignof__ keyword.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14306/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      faf6fd75
    • Dan Carpenter's avatar
      stk-webcam: fix an endian bug in stk_camera_read_reg() · d539f0aa
      Dan Carpenter authored
      commit d08876f5 upstream.
      
      We pass an int pointer to stk_camera_read_reg() but only write to the
      highest byte.  It's a bug on big endian systems and generally a nasty
      thing to do and doesn't match the write function either.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d539f0aa
    • Colin Ian King's avatar
      power: supply: bq2415x: check for NULL acpi_id to avoid null pointer dereference · f9437fa5
      Colin Ian King authored
      commit a1b94355 upstream.
      
      acpi_match_device can potentially return NULL, so it is prudent to
      check if acpi_id is null before it is dereferenced.  Add a check
      and an error message to indicate the failure.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9437fa5