1. 10 Nov, 2018 40 commits
    • Maciej W. Rozycki's avatar
      MIPS: Fix FCSR Cause bit handling for correct SIGFPE issue · 1c84d14e
      Maciej W. Rozycki authored
      [ Upstream commit 5a1aca44 ]
      
      Sanitize FCSR Cause bit handling, following a trail of past attempts:
      
      * commit 42495484 ("MIPS: ptrace: Fix FP context restoration FCSR
      regression"),
      
      * commit 443c4403 ("MIPS: Always clear FCSR cause bits after
      emulation"),
      
      * commit 64bedffe ("MIPS: Clear [MSA]FPE CSR.Cause after
      notify_die()"),
      
      * commit b1442d39 ("MIPS: Prevent user from setting FCSR cause
      bits"),
      
      * commit b54d2901517d ("Properly handle branch delay slots in connection
      with signals.").
      
      Specifically do not mask these bits out in ptrace(2) processing and send
      a SIGFPE signal instead whenever a matching pair of an FCSR Cause and
      Enable bit is seen as execution of an affected context is about to
      resume.  Only then clear Cause bits, and even then do not clear any bits
      that are set but masked with the respective Enable bits.  Adjust Cause
      bit clearing throughout code likewise, except within the FPU emulator
      proper where they are set according to IEEE 754 exceptions raised as the
      operation emulated executed.  Do so so that any IEEE 754 exceptions
      subject to their default handling are recorded like with operations
      executed by FPU hardware.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14460/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c84d14e
    • Vladis Dronov's avatar
      usbvision: revert commit 588afcc1 · af521c7f
      Vladis Dronov authored
      [ Upstream commit d5468d7a ]
      
      Commit 588afcc1 ("[media] usbvision fix overflow of interfaces
      array")' should be reverted, because:
      
      * "!dev->actconfig->interface[ifnum]" won't catch a case where the value
      is not NULL but some garbage. This way the system may crash later with
      GPF.
      
      * "(ifnum >= USB_MAXINTERFACES)" does not cover all the error
      conditions. "ifnum" should be compared to "dev->actconfig->
      desc.bNumInterfaces", i.e. compared to the number of "struct
      usb_interface" kzalloc()-ed, not to USB_MAXINTERFACES.
      
      * There is a "struct usb_device" leak in this error path, as there is
      usb_get_dev(), but no usb_put_dev() on this path.
      
      * There is a bug of the same type several lines below with number of
      endpoints. The code is accessing hard-coded second endpoint
      ("interface->endpoint[1].desc") which may not exist. It would be great
      to handle this in the same patch too.
      
      * All the concerns above are resolved by already-accepted commit fa52bd50
      ("[media] usbvision: fix crash on detecting device with invalid
      configuration")
      
      * Mailing list message:
      http://www.spinics.net/lists/linux-media/msg94832.htmlSigned-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v4.5
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af521c7f
    • Alexander Shishkin's avatar
      perf/core: Don't leak event in the syscall error path · 5796c70e
      Alexander Shishkin authored
      [ Upstream commit 201c2f85 ]
      
      In the error path, event_file not being NULL is used to determine
      whether the event itself still needs to be free'd, so fix it up to
      avoid leaking.
      Reported-by: default avatarLeon Yu <chianglungyu@gmail.com>
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: 13005627 ("perf: Do not double free")
      Link: http://lkml.kernel.org/r/87twk06yxp.fsf@ashishki-desk.ger.corp.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5796c70e
    • Raghava Aditya Renukunta's avatar
      aacraid: Start adapter after updating number of MSIX vectors · 93e8e691
      Raghava Aditya Renukunta authored
      [ Upstream commit 116d77fe ]
      
      The adapter has to be started after updating the number of MSIX Vectors
      
      Fixes: ecc479e0 (aacraid: Set correct MSIX count for EEH recovery)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93e8e691
    • Prarit Bhargava's avatar
      x86/PCI: Mark Broadwell-EP Home Agent 1 as having non-compliant BARs · 92fe37c0
      Prarit Bhargava authored
      [ Upstream commit da77b671 ]
      
      Commit b8941571 ("x86/PCI: Mark Broadwell-EP Home Agent & PCU as having
      non-compliant BARs") marked Home Agent 0 & PCU has having non-compliant
      BARs.  Home Agent 1 also has non-compliant BARs.
      
      Mark Home Agent 1 as having non-compliant BARs so the PCI core doesn't
      touch them.
      
      The problem with these devices is documented in the Xeon v4 specification
      update:
      
        BDF2          PCI BARs in the Home Agent Will Return Non-Zero Values
                      During Enumeration
      
        Problem:      During system initialization the Operating System may access
                      the standard PCI BARs (Base Address Registers).  Due to
                      this erratum, accesses to the Home Agent BAR registers (Bus
                      1; Device 18; Function 0,4; Offsets (0x14-0x24) will return
                      non-zero values.
      
        Implication:  The operating system may issue a warning.  Intel has not
                      observed any functional failures due to this erratum.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e5-v4-spec-update.html
      Fixes: b8941571 ("x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs")
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Andi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      92fe37c0
    • Jarkko Sakkinen's avatar
      tpm: fix: return rc when devm_add_action() fails · c447410b
      Jarkko Sakkinen authored
      [ Upstream commit 4f3b193d ]
      
      Call put_device() and return error code if devm_add_action() fails.
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Fixes: 8e0ee3c9 ("tpm: fix the cleanup of struct tpm_chip")
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c447410b
    • Arnd Bergmann's avatar
      thermal: allow u8500-thermal driver to be a module · c8a5f83f
      Arnd Bergmann authored
      [ Upstream commit 26716ce1 ]
      
      When the thermal subsystem is a loadable module, the u8500 driver
      fails to build:
      
      drivers/thermal/built-in.o: In function `db8500_thermal_probe':
      db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register'
      drivers/thermal/built-in.o: In function `db8500_thermal_work':
      db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update'
      
      This changes the symbol to a tristate, so Kconfig can track the
      dependency correctly.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c8a5f83f
    • Arnd Bergmann's avatar
      thermal: allow spear-thermal driver to be a module · 90f9ed93
      Arnd Bergmann authored
      [ Upstream commit 4d2f1794 ]
      
      When the thermal subsystem is a loadable module, the spear driver
      fails to build:
      
      drivers/thermal/built-in.o: In function `spear_thermal_exit':
      spear_thermal.c:(.text+0xf8): undefined reference to `thermal_zone_device_unregister'
      drivers/thermal/built-in.o: In function `spear_thermal_probe':
      spear_thermal.c:(.text+0x230): undefined reference to `thermal_zone_device_register'
      
      This changes the symbol to a tristate, so Kconfig can track the
      dependency correctly.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      90f9ed93
    • Jeff Mahoney's avatar
      btrfs: don't create or leak aliased root while cleaning up orphans · c1504091
      Jeff Mahoney authored
      [ Upstream commit 35bbb97f ]
      
      commit 909c3a22 (Btrfs: fix loading of orphan roots leading to BUG_ON)
      avoids the BUG_ON but can add an aliased root to the dead_roots list or
      leak the root.
      
      Since we've already been loading roots into the radix tree, we should
      use it before looking the root up on disk.
      
      Cc: <stable@vger.kernel.org> # 4.5
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c1504091
    • Peter Zijlstra's avatar
      sched/cgroup: Fix cgroup entity load tracking tear-down · 137b1ce3
      Peter Zijlstra authored
      [ Upstream commit 6fe1f348 ]
      
      When a cgroup's CPU runqueue is destroyed, it should remove its
      remaining load accounting from its parent cgroup.
      
      The current site for doing so it unsuited because its far too late and
      unordered against other cgroup removal (->css_free() will be, but we're also
      in an RCU callback).
      
      Put it in the ->css_offline() callback, which is the start of cgroup
      destruction, right after the group has been made unavailable to
      userspace. The ->css_offline() callbacks are called in hierarchical order
      after the following v4.4 commit:
      
        aa226ff4 ("cgroup: make sure a parent css isn't offlined before its children")
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160121212416.GL6357@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      137b1ce3
    • Florian Fainelli's avatar
      um: Avoid longjmp/setjmp symbol clashes with libpthread.a · 53025e7f
      Florian Fainelli authored
      [ Upstream commit f44f1e7d ]
      
      Building a statically linked UML kernel on a Centos 6.9 host resulted in
      the following linking failure (GCC 4.4, glibc-2.12):
      
      /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
      In function `siglongjmp':
      (.text+0x8490): multiple definition of `longjmp'
      arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
      first defined here
      /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
      In function `sem_open':
      (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
      `mkstemp'
      collect2: ld returned 1 exit status
      make[4]: *** [vmlinux] Error 1
      
      Adopt a solution similar to the one done for vmap where we define
      longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
      do rename the functions in arch/x86/um/setjmp_*.S accordingly.
      
      Fixes: a7df4716 ("um: link with -lpthread")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      53025e7f
    • Eric Dumazet's avatar
      ipv6: orphan skbs in reassembly unit · 274337f8
      Eric Dumazet authored
      [ Upstream commit 48cac18e ]
      
      Andrey reported a use-after-free in IPv6 stack.
      
      Issue here is that we free the socket while it still has skb
      in TX path and in some queues.
      
      It happens here because IPv6 reassembly unit messes skb->truesize,
      breaking skb_set_owner_w() badly.
      
      We fixed a similar issue for IPV4 in commit 8282f274 ("inet: frag:
      Always orphan skbs inside ip_defrag()")
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
      
      ==================================================================
      BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
      Read of size 8 at addr ffff880062da0060 by task a.out/4140
      
      page:ffffea00018b6800 count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x100000000008100(slab|head)
      raw: 0100000000008100 0000000000000000 0000000000000000 0000000180130013
      raw: dead000000000100 dead000000000200 ffff88006741f140 0000000000000000
      page dumped because: kasan: bad access detected
      
      CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       describe_address mm/kasan/report.c:262
       kasan_report_error+0x121/0x560 mm/kasan/report.c:370
       kasan_report mm/kasan/report.c:392
       __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
       sock_flag ./arch/x86/include/asm/bitops.h:324
       sock_wfree+0x118/0x120 net/core/sock.c:1631
       skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put ./include/net/inet_frag.h:133
       nf_ct_frag6_gather+0x1125/0x38b0 net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn ./include/linux/netfilter.h:102
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook ./include/linux/netfilter.h:212
       __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613
       rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x620 net/socket.c:848
       new_sync_write fs/read_write.c:499
       __vfs_write+0x483/0x760 fs/read_write.c:512
       vfs_write+0x187/0x530 fs/read_write.c:560
       SYSC_write fs/read_write.c:607
       SyS_write+0xfb/0x230 fs/read_write.c:599
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      RIP: 0033:0x7ff26e6f5b79
      RSP: 002b:00007ff268e0ed98 EFLAGS: 00000206 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007ff268e0f9c0 RCX: 00007ff26e6f5b79
      RDX: 0000000000000010 RSI: 0000000020f50fe1 RDI: 0000000000000003
      RBP: 00007ff26ebc1220 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
      R13: 00007ff268e0f9c0 R14: 00007ff26efec040 R15: 0000000000000003
      
      The buggy address belongs to the object at ffff880062da0000
       which belongs to the cache RAWv6 of size 1504
      The buggy address ffff880062da0060 is located 96 bytes inside
       of 1504-byte region [ffff880062da0000, ffff880062da05e0)
      
      Freed by task 4113:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
       slab_free_hook mm/slub.c:1352
       slab_free_freelist_hook mm/slub.c:1374
       slab_free mm/slub.c:2951
       kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
       sk_prot_free net/core/sock.c:1377
       __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sk_free+0x23/0x30 net/core/sock.c:1479
       sock_put ./include/net/sock.h:1638
       sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
       rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
       sock_release+0x8d/0x1e0 net/socket.c:599
       sock_close+0x16/0x20 net/socket.c:1063
       __fput+0x332/0x7f0 fs/file_table.c:208
       ____fput+0x15/0x20 fs/file_table.c:244
       task_work_run+0x19b/0x270 kernel/task_work.c:116
       exit_task_work ./include/linux/task_work.h:21
       do_exit+0x186b/0x2800 kernel/exit.c:839
       do_group_exit+0x149/0x420 kernel/exit.c:943
       SYSC_exit_group kernel/exit.c:954
       SyS_exit_group+0x1d/0x20 kernel/exit.c:952
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Allocated by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544
       slab_post_alloc_hook mm/slab.h:432
       slab_alloc_node mm/slub.c:2708
       slab_alloc mm/slub.c:2716
       kmem_cache_alloc+0x1af/0x250 mm/slub.c:2721
       sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1334
       sk_alloc+0x105/0x1010 net/core/sock.c:1396
       inet6_create+0x44d/0x1150 net/ipv6/af_inet6.c:183
       __sock_create+0x4f6/0x880 net/socket.c:1199
       sock_create net/socket.c:1239
       SYSC_socket net/socket.c:1269
       SyS_socket+0xf9/0x230 net/socket.c:1249
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Memory state around the buggy address:
       ffff880062d9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880062d9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff880062da0000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880062da0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880062da0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      274337f8
    • Eugenia Emantayev's avatar
      net/mlx4_en: Resolve dividing by zero in 32-bit system · 61918dbc
      Eugenia Emantayev authored
      [ Upstream commit 4850cf45 ]
      
      When doing roundup_pow_of_two for large enough number with
      bit 31, an overflow will occur and a value equal to 1 will
      be returned. In this case 1 will be subtracted from the return
      value and division by zero will be reached.
      
      Fixes: 31c128b6 ("net/mlx4_en: Choose time-stamping shift value according to HW frequency")
      Signed-off-by: default avatarEugenia Emantayev <eugenia@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      61918dbc
    • Mateusz Jurczyk's avatar
      af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers · 80176161
      Mateusz Jurczyk authored
      [ Upstream commit e3c42b61 ]
      
      Verify that the caller-provided sockaddr structure is large enough to
      contain the sa_family field, before accessing it in bind() and connect()
      handlers of the AF_IUCV socket. Since neither syscall enforces a minimum
      size of the corresponding memory region, very short sockaddrs (zero or
      one byte long) result in operating on uninitialized memory while
      referencing .sa_family.
      
      Fixes: 52a82e23 ("af_iucv: Validate socket address length in iucv_sock_bind()")
      Signed-off-by: default avatarMateusz Jurczyk <mjurczyk@google.com>
      [jwi: removed unneeded null-check for addr]
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      80176161
    • Andrey Ryabinin's avatar
      radix-tree: fix radix_tree_iter_retry() for tagged iterators. · 11eea056
      Andrey Ryabinin authored
      [ Upstream commit 3cb9185c ]
      
      radix_tree_iter_retry() resets slot to NULL, but it doesn't reset tags.
      Then NULL slot and non-zero iter.tags passed to radix_tree_next_slot()
      leading to crash:
      
        RIP: radix_tree_next_slot include/linux/radix-tree.h:473
          find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
        ....
        Call Trace:
          pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
          mpage_prepare_extent_to_map+0x321/0xa90 fs/ext4/inode.c:2516
          ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
          do_writepages+0x97/0x100 mm/page-writeback.c:2364
          __filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
          filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
          ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
          vfs_fsync_range+0x10a/0x250 fs/sync.c:195
          vfs_fsync fs/sync.c:209
          do_fsync+0x42/0x70 fs/sync.c:219
          SYSC_fdatasync fs/sync.c:232
          SyS_fdatasync+0x19/0x20 fs/sync.c:230
          entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207
      
      We must reset iterator's tags to bail out from radix_tree_next_slot()
      and go to the slow-path in radix_tree_next_chunk().
      
      Fixes: 46437f9a ("radix-tree: fix race in gang lookup")
      Link: http://lkml.kernel.org/r/1468495196-10604-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      11eea056
    • Matt Fleming's avatar
      x86/mm/pat: Prevent hang during boot when mapping pages · 9903f3ab
      Matt Fleming authored
      [ Upstream commit e535ec08 ]
      
      There's a mixture of signed 32-bit and unsigned 32-bit and 64-bit data
      types used for keeping track of how many pages have been mapped.
      
      This leads to hangs during boot when mapping large numbers of pages
      (multiple terabytes, as reported by Waiman) because those values are
      interpreted as being negative.
      
      commit 74256377 ("x86/mm/pat: Avoid truncation when converting
      cpa->numpages to address") fixed one of those bugs, but there is
      another lurking in __change_page_attr_set_clr().
      
      Additionally, the return value type for the populate_*() functions can
      return negative values when a large number of pages have been mapped,
      triggering the error paths even though no error occurred.
      
      Consistently use 64-bit types on 64-bit platforms when counting pages.
      Even in the signed case this gives us room for regions 8PiB
      (pebibytes) in size whilst still allowing the usual negative value
      error checking idiom.
      Reported-by: default avatarWaiman Long <waiman.long@hpe.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Scott J Norton <scott.norton@hpe.com>
      Cc: Douglas Hatch <doug.hatch@hpe.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9903f3ab
    • Srinivas Kandagatla's avatar
      ARM: dts: apq8064: add ahci ports-implemented mask · 011859fd
      Srinivas Kandagatla authored
      [ Upstream commit bb4add2c ]
      
      This patch adds new ports-implemented mask, which is required to get
      achi working on the mainline. Without this patch value read from
      PORTS_IMPL register which is zero would not enable any ports for
      software to use.
      
      Fixes: 566d1827 ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
      Cc: stable@vger.kernel.org # v4.5+
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      011859fd
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Skip more functions when doing stack tracing of events · 70b3d6c5
      Steven Rostedt (Red Hat) authored
      [ Upstream commit be54f69c ]
      
       # echo 1 > options/stacktrace
       # echo 1 > events/sched/sched_switch/enable
       # cat trace
                <idle>-0     [002] d..2  1982.525169: <stack trace>
       => save_stack_trace
       => __ftrace_trace_stack
       => trace_buffer_unlock_commit_regs
       => event_trigger_unlock_commit
       => trace_event_buffer_commit
       => trace_event_raw_event_sched_switch
       => __schedule
       => schedule
       => schedule_preempt_disabled
       => cpu_startup_entry
       => start_secondary
      
      The above shows that we are seeing 6 functions before ever making it to the
      caller of the sched_switch event.
      
       # echo stacktrace > events/sched/sched_switch/trigger
       # cat trace
                <idle>-0     [002] d..3  2146.335208: <stack trace>
       => trace_event_buffer_commit
       => trace_event_raw_event_sched_switch
       => __schedule
       => schedule
       => schedule_preempt_disabled
       => cpu_startup_entry
       => start_secondary
      
      The stacktrace trigger isn't as bad, because it adds its own skip to the
      stacktracing, but still has two events extra.
      
      One issue is that if the stacktrace passes its own "regs" then there should
      be no addition to the skip, as the regs will not include the functions being
      called. This was an issue that was fixed by commit 7717c6be ("tracing:
      Fix stacktrace skip depth in trace_buffer_unlock_commit_regs()" as adding
      the skip number for kprobes made the probes not have any stack at all.
      
      But since this is only an issue when regs is being used, a skip should be
      added if regs is NULL. Now we have:
      
       # echo 1 > options/stacktrace
       # echo 1 > events/sched/sched_switch/enable
       # cat trace
                <idle>-0     [000] d..2  1297.676333: <stack trace>
       => __schedule
       => schedule
       => schedule_preempt_disabled
       => cpu_startup_entry
       => rest_init
       => start_kernel
       => x86_64_start_reservations
       => x86_64_start_kernel
      
       # echo stacktrace > events/sched/sched_switch/trigger
       # cat trace
                <idle>-0     [002] d..3  1370.759745: <stack trace>
       => __schedule
       => schedule
       => schedule_preempt_disabled
       => cpu_startup_entry
       => start_secondary
      
      And kprobes are not touched.
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      70b3d6c5
    • Paul Bolle's avatar
      ser_gigaset: use container_of() instead of detour · 6b3d1619
      Paul Bolle authored
      [ Upstream commit 8d2c3ab4 ]
      
      The purpose of gigaset_device_release() is to kfree() the struct
      ser_cardstate that contains our struct device. This is done via a bit of
      a detour. First we make our struct device's driver_data point to the
      container of our struct ser_cardstate (which is a struct cardstate). In
      gigaset_device_release() we then retrieve that driver_data again. And
      after that we finally kfree() the struct ser_cardstate that was saved in
      the struct cardstate.
      
      All of this can be achieved much easier by using container_of() to get
      from our struct device to its container, struct ser_cardstate. Do so.
      
      Note that at the time the detour was implemented commit b8b2c7d8
      ("base/platform: assert that dev_pm_domain callbacks are called
      unconditionally") had just entered the tree. That commit disconnected
      our platform_device and our platform_driver. These were reconnected
      again in v4.5-rc2 through commit 25cad69f ("base/platform: Fix
      platform drivers with no probe callback"). And one of the consequences
      of that fix was that it broke the detour via driver_data. That's because
      it made __device_release_driver() stop being a NOP for our struct device
      and actually do stuff again. One of the things it now does, is setting
      our driver_data to NULL. That, in turn, makes it impossible for
      gigaset_device_release() to get to our struct cardstate. Which has the
      net effect of leaking a struct ser_cardstate at every call of this
      driver's tty close() operation. So using container_of() has the
      additional benefit of actually working.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Acked-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6b3d1619
    • David Herrmann's avatar
      net: drop write-only stack variable · ca4a744b
      David Herrmann authored
      [ Upstream commit 3575dbf2 ]
      
      Remove a write-only stack variable from unix_attach_fds(). This is a
      left-over from the security fix in:
      
          commit 712f4aad
          Author: willy tarreau <w@1wt.eu>
          Date:   Sun Jan 10 07:54:56 2016 +0100
      
              unix: properly account for FDs passed over unix sockets
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ca4a744b
    • Johannes Berg's avatar
      ipv6: suppress sparse warnings in IP6_ECN_set_ce() · 997a4944
      Johannes Berg authored
      [ Upstream commit c15c0ab1 ]
      
      Pass the correct type __wsum to csum_sub() and csum_add(). This doesn't
      really change anything since __wsum really *is* __be32, but removes the
      address space warnings from sparse.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Fixes: 34ae6a1a ("ipv6: update skb->csum when CE mark is propagated")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      997a4944
    • Eric Biggers's avatar
      KEYS: put keyring if install_session_keyring_to_cred() fails · 9aae17f8
      Eric Biggers authored
      [ Upstream commit d636bd9f ]
      
      In join_session_keyring(), if install_session_keyring_to_cred() were to
      fail, we would leak the keyring reference, just like in the bug fixed by
      commit 23567fd0 ("KEYS: Fix keyring ref leak in
      join_session_keyring()").  Fortunately this cannot happen currently, but
      we really should be more careful.  Do this by adding and using a new
      error label at which the keyring reference is dropped.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9aae17f8
    • Wenwen Wang's avatar
      net: cxgb3_main: fix a missing-check bug · 6596d0ab
      Wenwen Wang authored
      [ Upstream commit 2c05d88818ab6571816b93edce4d53703870d7ae ]
      
      In cxgb_extension_ioctl(), the command of the ioctl is firstly copied from
      the user-space buffer 'useraddr' to 'cmd' and checked through the
      switch statement. If the command is not as expected, an error code
      EOPNOTSUPP is returned. In the following execution, i.e., the cases of the
      switch statement, the whole buffer of 'useraddr' is copied again to a
      specific data structure, according to what kind of command is requested.
      However, after the second copy, there is no re-check on the newly-copied
      command. Given that the buffer 'useraddr' is in the user space, a malicious
      user can race to change the command between the two copies. By doing so,
      the attacker can supply malicious data to the kernel and cause undefined
      behavior.
      
      This patch adds a re-check in each case of the switch statement if there is
      a second copy in that case, to re-check whether the command obtained in the
      second copy is the same as the one in the first copy. If not, an error code
      EINVAL is returned.
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6596d0ab
    • Jiri Olsa's avatar
      perf/ring_buffer: Prevent concurent ring buffer access · 4f0336a8
      Jiri Olsa authored
      [ Upstream commit cd6fb677ce7e460c25bdd66f689734102ec7d642 ]
      
      Some of the scheduling tracepoints allow the perf_tp_event
      code to write to ring buffer under different cpu than the
      code is running on.
      
      This results in corrupted ring buffer data demonstrated in
      following perf commands:
      
        # perf record -e 'sched:sched_switch,sched:sched_wakeup' perf bench sched messaging
        # Running 'sched/messaging' benchmark:
        # 20 sender and receiver processes per group
        # 10 groups == 400 processes run
      
             Total time: 0.383 [sec]
        [ perf record: Woken up 8 times to write data ]
        0x42b890 [0]: failed to process type: -1765585640
        [ perf record: Captured and wrote 4.825 MB perf.data (29669 samples) ]
      
        # perf report --stdio
        0x42b890 [0]: failed to process type: -1765585640
      
      The reason for the corruption are some of the scheduling tracepoints,
      that have __perf_task dfined and thus allow to store data to another
      cpu ring buffer:
      
        sched_waking
        sched_wakeup
        sched_wakeup_new
        sched_stat_wait
        sched_stat_sleep
        sched_stat_iowait
        sched_stat_blocked
      
      The perf_tp_event function first store samples for current cpu
      related events defined for tracepoint:
      
          hlist_for_each_entry_rcu(event, head, hlist_entry)
            perf_swevent_event(event, count, &data, regs);
      
      And then iterates events of the 'task' and store the sample
      for any task's event that passes tracepoint checks:
      
        ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]);
      
        list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
          if (event->attr.type != PERF_TYPE_TRACEPOINT)
            continue;
          if (event->attr.config != entry->type)
            continue;
      
          perf_swevent_event(event, count, &data, regs);
        }
      
      Above code can race with same code running on another cpu,
      ending up with 2 cpus trying to store under the same ring
      buffer, which is specifically not allowed.
      
      This patch prevents the problem, by allowing only events with the same
      current cpu to receive the event.
      
      NOTE: this requires the use of (per-task-)per-cpu buffers for this
      feature to work; perf-record does this.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      [peterz: small edits to Changelog]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      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: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: e6dab5ff ("perf/trace: Add ability to set a target task for events")
      Link: http://lkml.kernel.org/r/20180923161343.GB15054@kravaSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4f0336a8
    • Florian Fainelli's avatar
      smsc95xx: Check for Wake-on-LAN modes · 863fdd16
      Florian Fainelli authored
      [ Upstream commit c530c471ba37bdd9fe1c7185b01455c00ae606fb ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: e0e474a8 ("smsc95xx: add wol magic packet support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      863fdd16
    • Florian Fainelli's avatar
      smsc75xx: Check for Wake-on-LAN modes · 66e43f42
      Florian Fainelli authored
      [ Upstream commit 9c734b2769a73eea2e9e9767c0e0bf839ff23679 ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: 6c636503 ("smsc75xx: add wol magic packet support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      66e43f42
    • Florian Fainelli's avatar
      r8152: Check for supported Wake-on-LAN Modes · 2bb181d8
      Florian Fainelli authored
      [ Upstream commit f2750df1548bd8a2b060eb609fc43ca82811af4c ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: 21ff2e89 ("r8152: support WOL")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2bb181d8
    • Florian Fainelli's avatar
      sr9800: Check for supported Wake-on-LAN modes · 24665cbd
      Florian Fainelli authored
      [ Upstream commit c5cb93e994ffb43b7b3b1ff10b9f928f54574a36 ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: 19a38d8e ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      24665cbd
    • Florian Fainelli's avatar
      lan78xx: Check for supported Wake-on-LAN modes · 04d846cd
      Florian Fainelli authored
      [ Upstream commit eb9ad088f96653a26b340f7c447c44cf023d5cdc ]
      
      The driver supports a fair amount of Wake-on-LAN modes, but is not
      checking that the user specified one that is supported.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarWoojung Huh <Woojung.Huh@Microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      04d846cd
    • Florian Fainelli's avatar
      ax88179_178a: Check for supported Wake-on-LAN modes · f3d71a32
      Florian Fainelli authored
      [ Upstream commit 5ba6b4aa9a410c5e2c6417df52b5e2118ea9b467 ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: e2ca90c2 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f3d71a32
    • Florian Fainelli's avatar
      asix: Check for supported Wake-on-LAN modes · 644d1918
      Florian Fainelli authored
      [ Upstream commit c4ce446e33d7a0e978256ac6fea4c80e59d9de5f ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: 2e55cc72 ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      644d1918
    • Lubomir Rintel's avatar
      pxa168fb: prepare the clock · df2d090b
      Lubomir Rintel authored
      [ Upstream commit d85536cde91fcfed6fb8d983783bd2b92c843939 ]
      
      Add missing prepare/unprepare operations for fbi->clk,
      this fixes following kernel warning:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:874 clk_core_enable+0x2c/0x1b0
        Enabling unprepared disp0_clk
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc8-00032-g02b43ddd4f21-dirty #25
        Hardware name: Marvell MMP2 (Device Tree Support)
        [<c010f7cc>] (unwind_backtrace) from [<c010cc6c>] (show_stack+0x10/0x14)
        [<c010cc6c>] (show_stack) from [<c011dab4>] (__warn+0xd8/0xf0)
        [<c011dab4>] (__warn) from [<c011db10>] (warn_slowpath_fmt+0x44/0x6c)
        [<c011db10>] (warn_slowpath_fmt) from [<c043898c>] (clk_core_enable+0x2c/0x1b0)
        [<c043898c>] (clk_core_enable) from [<c0439ec8>] (clk_core_enable_lock+0x18/0x2c)
        [<c0439ec8>] (clk_core_enable_lock) from [<c0436698>] (pxa168fb_probe+0x464/0x6ac)
        [<c0436698>] (pxa168fb_probe) from [<c04779a0>] (platform_drv_probe+0x48/0x94)
        [<c04779a0>] (platform_drv_probe) from [<c0475bec>] (driver_probe_device+0x328/0x470)
        [<c0475bec>] (driver_probe_device) from [<c0475de4>] (__driver_attach+0xb0/0x124)
        [<c0475de4>] (__driver_attach) from [<c0473c38>] (bus_for_each_dev+0x64/0xa0)
        [<c0473c38>] (bus_for_each_dev) from [<c0474ee0>] (bus_add_driver+0x1b8/0x230)
        [<c0474ee0>] (bus_add_driver) from [<c0476a20>] (driver_register+0xac/0xf0)
        [<c0476a20>] (driver_register) from [<c0102dd4>] (do_one_initcall+0xb8/0x1f0)
        [<c0102dd4>] (do_one_initcall) from [<c0b010a0>] (kernel_init_freeable+0x294/0x2e0)
        [<c0b010a0>] (kernel_init_freeable) from [<c07e9eb8>] (kernel_init+0x8/0x10c)
        [<c07e9eb8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
        Exception stack(0xd008bfb0 to 0xd008bff8)
        bfa0:                                     00000000 00000000 00000000 00000000
        bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
        ---[ end trace c0af40f9e2ed7cb4 ]---
      Signed-off-by: default avatarLubomir Rintel <lkundrak@v3.sk>
      [b.zolnierkie: enhance patch description a bit]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df2d090b
    • Matias Karhumaa's avatar
      Bluetooth: SMP: fix crash in unpairing · b0c52fbf
      Matias Karhumaa authored
      [ Upstream commit cb28c306b93b71f2741ce1a5a66289db26715f4d ]
      
      In case unpair_device() was called through mgmt interface at the same time
      when pairing was in progress, Bluetooth kernel module crash was seen.
      
      [  600.351225] general protection fault: 0000 [#1] SMP PTI
      [  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G           OE     4.19.0-rc1+ #1
      [  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
      [  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351295] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      [  600.351302] Call Trace:
      [  600.351325]  smp_failure+0x4f/0x70 [bluetooth]
      [  600.351345]  smp_cancel_pairing+0x74/0x80 [bluetooth]
      [  600.351370]  unpair_device+0x1c1/0x330 [bluetooth]
      [  600.351399]  hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
      [  600.351409]  ? apparmor_socket_sendmsg+0x1e/0x20
      [  600.351417]  sock_sendmsg+0x3e/0x50
      [  600.351422]  sock_write_iter+0x85/0xf0
      [  600.351429]  do_iter_readv_writev+0x12b/0x1b0
      [  600.351434]  do_iter_write+0x87/0x1a0
      [  600.351439]  vfs_writev+0x98/0x110
      [  600.351443]  ? ep_poll+0x16d/0x3d0
      [  600.351447]  ? ep_modify+0x73/0x170
      [  600.351451]  do_writev+0x61/0xf0
      [  600.351455]  ? do_writev+0x61/0xf0
      [  600.351460]  __x64_sys_writev+0x1c/0x20
      [  600.351465]  do_syscall_64+0x5a/0x110
      [  600.351471]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  600.351474] RIP: 0033:0x7fb2bdb62fe0
      [  600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
      [  600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      [  600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0
      [  600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004
      [  600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000
      [  600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001
      [  600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000
      [  600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
      [  600.351569]  snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
      [  600.351637] ---[ end trace e49e9f1df09c94fb ]---
      [  600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351684] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351686] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      
      Crash happened because list_del_rcu() was called twice for smp->ltk. This
      was possible if unpair_device was called right after ltk was generated
      but before keys were distributed.
      
      In this commit smp_cancel_pairing was refactored to cancel pairing if it
      is in progress and otherwise just removes keys. Once keys are removed from
      rcu list, pointers to smp context's keys are set to NULL to make sure
      removed list items are not accessed later.
      
      This commit also adjusts the functionality of mgmt unpair_device() little
      bit. Previously pairing was canceled only if pairing was in state that
      keys were already generated. With this commit unpair_device() cancels
      pairing already in earlier states.
      
      Bug was found by fuzzing kernel SMP implementation using Synopsys
      Defensics.
      Reported-by: default avatarPekka Oikarainen <pekka.oikarainen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b0c52fbf
    • Martin Willi's avatar
      mac80211_hwsim: do not omit multicast announce of first added radio · 6879c047
      Martin Willi authored
      [ Upstream commit 28ef8b49a338dc1844e86b7954cfffc7dfa2660a ]
      
      The allocation of hwsim radio identifiers uses a post-increment from 0,
      so the first radio has idx 0. This idx is explicitly excluded from
      multicast announcements ever since, but it is unclear why.
      
      Drop that idx check and announce the first radio as well. This makes
      userspace happy if it relies on these events.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6879c047
    • Sean Tranchetti's avatar
      xfrm: validate template mode · 5217bec5
      Sean Tranchetti authored
      [ Upstream commit 32bf94fb5c2ec4ec842152d0e5937cd4bb6738fa ]
      
      XFRM mode parameters passed as part of the user templates
      in the IP_XFRM_POLICY are never properly validated. Passing
      values other than valid XFRM modes can cause stack-out-of-bounds
      reads to occur later in the XFRM processing:
      
      [  140.535608] ================================================================
      [  140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
      [  140.550306] Read of size 4 at addr ffffffc0238a7a58 by task repro/5148
      [  140.557369]
      [  140.558927] Call trace:
      [  140.558936] dump_backtrace+0x0/0x388
      [  140.558940] show_stack+0x24/0x30
      [  140.558946] __dump_stack+0x24/0x2c
      [  140.558949] dump_stack+0x8c/0xd0
      [  140.558956] print_address_description+0x74/0x234
      [  140.558960] kasan_report+0x240/0x264
      [  140.558963] __asan_report_load4_noabort+0x2c/0x38
      [  140.558967] xfrm_state_find+0x17e4/0x1cc4
      [  140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
      [  140.558975] xfrm_lookup+0x238/0x1444
      [  140.558977] xfrm_lookup_route+0x48/0x11c
      [  140.558984] ip_route_output_flow+0x88/0xc4
      [  140.558991] raw_sendmsg+0xa74/0x266c
      [  140.558996] inet_sendmsg+0x258/0x3b0
      [  140.559002] sock_sendmsg+0xbc/0xec
      [  140.559005] SyS_sendto+0x3a8/0x5a8
      [  140.559008] el0_svc_naked+0x34/0x38
      [  140.559009]
      [  140.592245] page dumped because: kasan: bad access detected
      [  140.597981] page_owner info is not active (free page?)
      [  140.603267]
      [  140.653503] ================================================================
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5217bec5
    • Thomas Petazzoni's avatar
      ARM: 8799/1: mm: fix pci_ioremap_io() offset check · f4c24fd3
      Thomas Petazzoni authored
      [ Upstream commit 3a58ac65e2d7969bcdf1b6acb70fa4d12a88e53e ]
      
      IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e
      something like 0xfffff (and not 0x100000).
      
      Therefore, when offset = 0xf0000 is passed as argument, this function
      fails even though the offset + SZ_64K fits below the
      IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space
      not usable as it cannot be mapped.
      
      This patch fixes that by substracing 1 to offset + SZ_64K, so that we
      compare the addrss of the last byte of the I/O space against
      IO_SPACE_LIMIT instead of the address of the first byte of what is
      after the I/O space.
      
      Fixes: c2794437 ("ARM: Add fixed PCI i/o mapping")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f4c24fd3
    • Andrei Otcheretianski's avatar
      cfg80211: reg: Init wiphy_idx in regulatory_hint_core() · db420bc4
      Andrei Otcheretianski authored
      [ Upstream commit 24f33e64fcd0d50a4b1a8e5b41bd0257aa66b0e8 ]
      
      Core regulatory hints didn't set wiphy_idx to WIPHY_IDX_INVALID. Since
      the regulatory request is zeroed, wiphy_idx was always implicitly set to
      0. This resulted in updating only phy #0.
      Fix that.
      
      Fixes: 806a9e39 ("cfg80211: make regulatory_request use wiphy_idx instead of wiphy")
      Signed-off-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      [add fixes tag]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db420bc4
    • Andrei Otcheretianski's avatar
      mac80211: Always report TX status · 7402bc9c
      Andrei Otcheretianski authored
      [ Upstream commit 8682250b3c1b75a45feb7452bc413d004cfe3778 ]
      
      If a frame is dropped for any reason, mac80211 wouldn't report the TX
      status back to user space.
      
      As the user space may rely on the TX_STATUS to kick its state
      machines, resends etc, it's better to just report this frame as not
      acked instead.
      Signed-off-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7402bc9c
    • Thadeu Lima de Souza Cascardo's avatar
      xfrm6: call kfree_skb when skb is toobig · 4e16c61e
      Thadeu Lima de Souza Cascardo authored
      [ Upstream commit 215ab0f021c9fea3c18b75e7d522400ee6a49990 ]
      
      After commit d6990976af7c5d8f55903bfb4289b6fb030bf754 ("vti6: fix PMTU caching
      and reporting on xmit"), some too big skbs might be potentially passed down to
      __xfrm6_output, causing it to fail to transmit but not free the skb, causing a
      leak of skb, and consequentially a leak of dst references.
      
      After running pmtu.sh, that shows as failure to unregister devices in a namespace:
      
      [  311.397671] unregister_netdevice: waiting for veth_b to become free. Usage count = 1
      
      The fix is to call kfree_skb in case of transmit failures.
      
      Fixes: dd767856 ("xfrm6: Don't call icmpv6_send on local error")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Reviewed-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e16c61e
    • Steffen Klassert's avatar
      xfrm: Validate address prefix lengths in the xfrm selector. · 5ce93bd4
      Steffen Klassert authored
      [ Upstream commit 07bf7908950a8b14e81aa1807e3c667eab39287a ]
      
      We don't validate the address prefix lengths in the xfrm
      selector we got from userspace. This can lead to undefined
      behaviour in the address matching functions if the prefix
      is too big for the given address family. Fix this by checking
      the prefixes and refuse SA/policy insertation when a prefix
      is invalid.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarAir Icy <icytxw@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5ce93bd4