1. 31 5月, 2019 2 次提交
  2. 26 5月, 2019 38 次提交
    • G
      Linux 4.19.46 · 8b2fc005
      Greg Kroah-Hartman 提交于
      8b2fc005
    • Y
      fbdev: sm712fb: fix memory frequency by avoiding a switch/case fallthrough · fcac7169
      Yifeng Li 提交于
      commit 9dc20113988b9a75ea6b3abd68dc45e2d73ccdab upstream.
      
      A fallthrough in switch/case was introduced in f627caf55b8e ("fbdev:
      sm712fb: fix crashes and garbled display during DPMS modesetting"),
      due to my copy-paste error, which would cause the memory clock frequency
      for SM720 to be programmed to SM712.
      
      Since it only reprograms the clock to a different frequency, it's only
      a benign issue without visible side-effect, so it also evaded Sudip
      Mukherjee's code review and regression tests. scripts/checkpatch.pl
      also failed to discover the issue, possibly due to nested switch
      statements.
      
      This issue was found by Stephen Rothwell by building linux-next with
      -Wimplicit-fallthrough.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Fixes: f627caf55b8e ("fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting")
      Signed-off-by: NYifeng Li <tomli@tomli.me>
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcac7169
    • D
      bpf, lru: avoid messing with eviction heuristics upon syscall lookup · 107e215c
      Daniel Borkmann 提交于
      commit 50b045a8c0ccf44f76640ac3eea8d80ca53979a3 upstream.
      
      One of the biggest issues we face right now with picking LRU map over
      regular hash table is that a map walk out of user space, for example,
      to just dump the existing entries or to remove certain ones, will
      completely mess up LRU eviction heuristics and wrong entries such
      as just created ones will get evicted instead. The reason for this
      is that we mark an entry as "in use" via bpf_lru_node_set_ref() from
      system call lookup side as well. Thus upon walk, all entries are
      being marked, so information of actual least recently used ones
      are "lost".
      
      In case of Cilium where it can be used (besides others) as a BPF
      based connection tracker, this current behavior causes disruption
      upon control plane changes that need to walk the map from user space
      to evict certain entries. Discussion result from bpfconf [0] was that
      we should simply just remove marking from system call side as no
      good use case could be found where it's actually needed there.
      Therefore this patch removes marking for regular LRU and per-CPU
      flavor. If there ever should be a need in future, the behavior could
      be selected via map creation flag, but due to mentioned reason we
      avoid this here.
      
        [0] http://vger.kernel.org/bpfconf.html
      
      Fixes: 29ba732a ("bpf: Add BPF_MAP_TYPE_LRU_HASH")
      Fixes: 8f844938 ("bpf: Add BPF_MAP_TYPE_LRU_PERCPU_HASH")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      107e215c
    • D
      bpf: add map_lookup_elem_sys_only for lookups from syscall side · 2bb3c547
      Daniel Borkmann 提交于
      commit c6110222c6f49ea68169f353565eb865488a8619 upstream.
      
      Add a callback map_lookup_elem_sys_only() that map implementations
      could use over map_lookup_elem() from system call side in case the
      map implementation needs to handle the latter differently than from
      the BPF data path. If map_lookup_elem_sys_only() is set, this will
      be preferred pick for map lookups out of user space. This hook is
      used in a follow-up fix for LRU map, but once development window
      opens, we can convert other map types from map_lookup_elem() (here,
      the one called upon BPF_MAP_LOOKUP_ELEM cmd is meant) over to use
      the callback to simplify and clean up the latter.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      2bb3c547
    • C
      bpf: relax inode permission check for retrieving bpf program · 3ded3aaa
      Chenbo Feng 提交于
      commit e547ff3f803e779a3898f1f48447b29f43c54085 upstream.
      
      For iptable module to load a bpf program from a pinned location, it
      only retrieve a loaded program and cannot change the program content so
      requiring a write permission for it might not be necessary.
      Also when adding or removing an unrelated iptable rule, it might need to
      flush and reload the xt_bpf related rules as well and triggers the inode
      permission check. It might be better to remove the write premission
      check for the inode so we won't need to grant write access to all the
      processes that flush and restore iptables rules.
      Signed-off-by: NChenbo Feng <fengc@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ded3aaa
    • G
      Revert "selftests/bpf: skip verifier tests for unsupported program types" · c33563e9
      Greg Kroah-Hartman 提交于
      This reverts commit 118d38a3 which is
      commit 8184d44c9a577a2f1842ed6cc844bfd4a9981d8e upstream.
      
      Tommi reports that this patch breaks the build, it's not really needed
      so let's revert it.
      Reported-by: NTommi Rantala <tommi.t.rantala@nokia.com>
      Cc: Stanislav Fomichev <sdf@google.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c33563e9
    • J
      driver core: Postpone DMA tear-down until after devres release for probe failure · 90110ffd
      John Garry 提交于
      commit 0b777eee88d712256ba8232a9429edb17c4f9ceb upstream.
      
      In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
      devres release"), we changed the ordering of tearing down the device DMA
      ops and releasing all the device's resources; this was because the DMA ops
      should be maintained until we release the device's managed DMA memories.
      
      However, we have seen another crash on an arm64 system when a
      device driver probe fails:
      
        hisi_sas_v3_hw 0000:74:02.0: Adding to iommu group 2
        scsi host1: hisi_sas_v3_hw
        BUG: Bad page state in process swapper/0  pfn:313f5
        page:ffff7e0000c4fd40 count:1 mapcount:0
        mapping:0000000000000000 index:0x0
        flags: 0xfffe00000001000(reserved)
        raw: 0fffe00000001000 ffff7e0000c4fd48 ffff7e0000c4fd48
      0000000000000000
        raw: 0000000000000000 0000000000000000 00000001ffffffff
      0000000000000000
        page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
        bad because of flags: 0x1000(reserved)
        Modules linked in:
        CPU: 49 PID: 1 Comm: swapper/0 Not tainted
      5.1.0-rc1-43081-g22d97fd-dirty #1433
        Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI
      RC0 - V1.12.01 01/29/2019
        Call trace:
        dump_backtrace+0x0/0x118
        show_stack+0x14/0x1c
        dump_stack+0xa4/0xc8
        bad_page+0xe4/0x13c
        free_pages_check_bad+0x4c/0xc0
        __free_pages_ok+0x30c/0x340
        __free_pages+0x30/0x44
        __dma_direct_free_pages+0x30/0x38
        dma_direct_free+0x24/0x38
        dma_free_attrs+0x9c/0xd8
        dmam_release+0x20/0x28
        release_nodes+0x17c/0x220
        devres_release_all+0x34/0x54
        really_probe+0xc4/0x2c8
        driver_probe_device+0x58/0xfc
        device_driver_attach+0x68/0x70
        __driver_attach+0x94/0xdc
        bus_for_each_dev+0x5c/0xb4
        driver_attach+0x20/0x28
        bus_add_driver+0x14c/0x200
        driver_register+0x6c/0x124
        __pci_register_driver+0x48/0x50
        sas_v3_pci_driver_init+0x20/0x28
        do_one_initcall+0x40/0x25c
        kernel_init_freeable+0x2b8/0x3c0
        kernel_init+0x10/0x100
        ret_from_fork+0x10/0x18
        Disabling lock debugging due to kernel taint
        BUG: Bad page state in process swapper/0  pfn:313f6
        page:ffff7e0000c4fd80 count:1 mapcount:0
      mapping:0000000000000000 index:0x0
      [   89.322983] flags: 0xfffe00000001000(reserved)
        raw: 0fffe00000001000 ffff7e0000c4fd88 ffff7e0000c4fd88
      0000000000000000
        raw: 0000000000000000 0000000000000000 00000001ffffffff
      0000000000000000
      
      The crash occurs for the same reason.
      
      In this case, on the really_probe() failure path, we are still clearing
      the DMA ops prior to releasing the device's managed memories.
      
      This patch fixes this issue by reordering the DMA ops teardown and the
      call to devres_release_all() on the failure path.
      Reported-by: NXiang Chen <chenxiang66@hisilicon.com>
      Tested-by: NXiang Chen <chenxiang66@hisilicon.com>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      [jpg: backport to 4.19.x and earlier]
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90110ffd
    • N
      md/raid: raid5 preserve the writeback action after the parity check · 43090805
      Nigel Croxon 提交于
      commit b2176a1dfb518d870ee073445d27055fea64dfb8 upstream.
      
      The problem is that any 'uptodate' vs 'disks' check is not precise
      in this path. Put a "WARN_ON(!test_bit(R5_UPTODATE, &dev->flags)" on the
      device that might try to kick off writes and then skip the action.
      Better to prevent the raid driver from taking unexpected action *and* keep
      the system alive vs killing the machine with BUG_ON.
      
      Note: fixed warning reported by kbuild test robot <lkp@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NNigel Croxon <ncroxon@redhat.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43090805
    • S
      Revert "Don't jump to compute_result state from check_result state" · 3d25b7f5
      Song Liu 提交于
      commit a25d8c327bb41742dbd59f8c545f59f3b9c39983 upstream.
      
      This reverts commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Nigel Croxon <ncroxon@redhat.com>
      Cc: Xiao Ni <xni@redhat.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d25b7f5
    • J
      perf/x86/intel: Fix race in intel_pmu_disable_event() · a0b1dde1
      Jiri Olsa 提交于
      [ Upstream commit 6f55967ad9d9752813e36de6d5fdbd19741adfc7 ]
      
      New race in x86_pmu_stop() was introduced by replacing the
      atomic __test_and_clear_bit() of cpuc->active_mask by separate
      test_bit() and __clear_bit() calls in the following commit:
      
        3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler")
      
      The race causes panic for PEBS events with enabled callchains:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
        ...
        RIP: 0010:perf_prepare_sample+0x8c/0x530
        Call Trace:
         <NMI>
         perf_event_output_forward+0x2a/0x80
         __perf_event_overflow+0x51/0xe0
         handle_pmi_common+0x19e/0x240
         intel_pmu_handle_irq+0xad/0x170
         perf_event_nmi_handler+0x2e/0x50
         nmi_handle+0x69/0x110
         default_do_nmi+0x3e/0x100
         do_nmi+0x11a/0x180
         end_repeat_nmi+0x16/0x1a
        RIP: 0010:native_write_msr+0x6/0x20
        ...
         </NMI>
         intel_pmu_disable_event+0x98/0xf0
         x86_pmu_stop+0x6e/0xb0
         x86_pmu_del+0x46/0x140
         event_sched_out.isra.97+0x7e/0x160
        ...
      
      The event is configured to make samples from PEBS drain code,
      but when it's disabled, we'll go through NMI path instead,
      where data->callchain will not get allocated and we'll crash:
      
                x86_pmu_stop
                  test_bit(hwc->idx, cpuc->active_mask)
                  intel_pmu_disable_event(event)
                  {
                    ...
                    intel_pmu_pebs_disable(event);
                    ...
      
      EVENT OVERFLOW ->  <NMI>
                           intel_pmu_handle_irq
                             handle_pmi_common
         TEST PASSES ->        test_bit(bit, cpuc->active_mask))
                                 perf_event_overflow
                                   perf_prepare_sample
                                   {
                                     ...
                                     if (!(sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
                                           data->callchain = perf_callchain(event, regs);
      
               CRASH ->              size += data->callchain->nr;
                                   }
                         </NMI>
                    ...
                    x86_pmu_disable_event(event)
                  }
      
                  __clear_bit(hwc->idx, cpuc->active_mask);
      
      Fixing this by disabling the event itself before setting
      off the PEBS bit.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Arcari <darcari@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Lendacky Thomas <Thomas.Lendacky@amd.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: 3966c3feca3f ("x86/perf/amd: Remove need to check "running" bit in NMI handler")
      Link: http://lkml.kernel.org/r/20190504151556.31031-1-jolsa@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a0b1dde1
    • A
      perf bench numa: Add define for RUSAGE_THREAD if not present · 7aea2f94
      Arnaldo Carvalho de Melo 提交于
      [ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ]
      
      While cross building perf to the ARC architecture on a fedora 30 host,
      we were failing with:
      
            CC       /tmp/build/perf/bench/numa.o
        bench/numa.c: In function ‘worker_thread’:
        bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’?
          getrusage(RUSAGE_THREAD, &rusage);
                    ^~~~~~~~~~~~~
                    SIGEV_THREAD
        bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in
      
      [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1
      arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
      [perfbuilder@60d5802468f6 perf]$
      
      Trying to reproduce a report by Vineet, I noticed that, with just
      cross-built zlib and numactl libraries, I ended up with the above
      failure.
      
      So, since RUSAGE_THREAD is available as a define, check for that and
      numactl libraries, I ended up with the above failure.
      
      So, since RUSAGE_THREAD is available as a define in the system headers,
      check if it is defined in the 'perf bench numa' sources and define it if
      not.
      
      Now it builds and I have to figure out if the problem reported by Vineet
      only takes place if we have libelf or some other library available.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0amk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7aea2f94
    • A
      ufs: fix braino in ufs_get_inode_gid() for solaris UFS flavour · a06fdd99
      Al Viro 提交于
      [ Upstream commit 4e9036042fedaffcd868d7f7aa948756c48c637d ]
      
      To choose whether to pick the GID from the old (16bit) or new (32bit)
      field, we should check if the old gid field is set to 0xffff.  Mainline
      checks the old *UID* field instead - cut'n'paste from the corresponding
      code in ufs_get_inode_uid().
      
      Fixes: 252e211eSigned-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a06fdd99
    • G
      x86/mm/mem_encrypt: Disable all instrumentation for early SME setup · f037116f
      Gary Hook 提交于
      [ Upstream commit b51ce3744f115850166f3d6c292b9c8cb849ad4f ]
      
      Enablement of AMD's Secure Memory Encryption feature is determined very
      early after start_kernel() is entered. Part of this procedure involves
      scanning the command line for the parameter 'mem_encrypt'.
      
      To determine intended state, the function sme_enable() uses library
      functions cmdline_find_option() and strncmp(). Their use occurs early
      enough such that it cannot be assumed that any instrumentation subsystem
      is initialized.
      
      For example, making calls to a KASAN-instrumented function before KASAN
      is set up will result in the use of uninitialized memory and a boot
      failure.
      
      When AMD's SME support is enabled, conditionally disable instrumentation
      of these dependent functions in lib/string.c and arch/x86/lib/cmdline.c.
      
       [ bp: Get rid of intermediary nostackp var and cleanup whitespace. ]
      
      Fixes: aca20d54 ("x86/mm: Add support to make use of Secure Memory Encryption")
      Reported-by: NLi RongQing <lirongqing@baidu.com>
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Boris Brezillon <bbrezillon@kernel.org>
      Cc: Coly Li <colyli@suse.de>
      Cc: "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Cc: "luto@kernel.org" <luto@kernel.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: "mingo@redhat.com" <mingo@redhat.com>
      Cc: "peterz@infradead.org" <peterz@infradead.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/155657657552.7116.18363762932464011367.stgit@sosrh3.amd.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      f037116f
    • T
      sched/cpufreq: Fix kobject memleak · 290da8e7
      Tobin C. Harding 提交于
      [ Upstream commit 9a4f26cc98d81b67ecc23b890c28e2df324e29f3 ]
      
      Currently the error return path from kobject_init_and_add() is not
      followed by a call to kobject_put() - which means we are leaking
      the kobject.
      
      Fix it by adding a call to kobject_put() in the error path of
      kobject_init_and_add().
      Signed-off-by: NTobin C. Harding <tobin@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tobin C. Harding <tobin@kernel.org>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Link: http://lkml.kernel.org/r/20190430001144.24890-1-tobin@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      290da8e7
    • L
      iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb() · 2da19da7
      Luca Coelho 提交于
      [ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ]
      
      We don't check for the validity of the lengths in the packet received
      from the firmware.  If the MPDU length received in the rx descriptor
      is too short to contain the header length and the crypt length
      together, we may end up trying to copy a negative number of bytes
      (headlen - hdrlen < 0) which will underflow and cause us to try to
      copy a huge amount of data.  This causes oopses such as this one:
      
      BUG: unable to handle kernel paging request at ffff896be2970000
      PGD 5e201067 P4D 5e201067 PUD 5e205067 PMD 16110d063 PTE 8000000162970161
      Oops: 0003 [#1] PREEMPT SMP NOPTI
      CPU: 2 PID: 1824 Comm: irq/134-iwlwifi Not tainted 4.19.33-04308-geea41cf4930f #1
      Hardware name: [...]
      RIP: 0010:memcpy_erms+0x6/0x10
      Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3
       0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
      RSP: 0018:ffffa4630196fc60 EFLAGS: 00010287
      RAX: ffff896be2924618 RBX: ffff896bc8ecc600 RCX: 00000000fffb4610
      RDX: 00000000fffffff8 RSI: ffff896a835e2a38 RDI: ffff896be2970000
      RBP: ffffa4630196fd30 R08: ffff896bc8ecc600 R09: ffff896a83597000
      R10: ffff896bd6998400 R11: 000000000200407f R12: ffff896a83597050
      R13: 00000000fffffff8 R14: 0000000000000010 R15: ffff896a83597038
      FS:  0000000000000000(0000) GS:ffff896be8280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff896be2970000 CR3: 000000005dc12002 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       iwl_mvm_rx_mpdu_mq+0xb51/0x121b [iwlmvm]
       iwl_pcie_rx_handle+0x58c/0xa89 [iwlwifi]
       iwl_pcie_irq_rx_msix_handler+0xd9/0x12a [iwlwifi]
       irq_thread_fn+0x24/0x49
       irq_thread+0xb0/0x122
       kthread+0x138/0x140
       ret_from_fork+0x1f/0x40
      
      Fix that by checking the lengths for correctness and trigger a warning
      to show that we have received wrong data.
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2da19da7
    • B
      qmi_wwan: new Wistron, ZTE and D-Link devices · 7341daa0
      Bjørn Mork 提交于
      [ Upstream commit 88ef66a28391ea7b624bfb7508a5b015c13b28f3 ]
      
      Adding device entries found in vendor modified versions of this
      driver.  Function maps for some of the devices follow:
      
      WNC D16Q1, D16Q5, D18Q1 LTE CAT3 module (1435:0918)
      
      MI_00 Qualcomm HS-USB Diagnostics
      MI_01 Android Debug interface
      MI_02 Qualcomm HS-USB Modem
      MI_03 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_04 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_05 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_06 USB Mass Storage Device
      
       T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
       D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
       P:  Vendor=1435 ProdID=0918 Rev= 2.32
       S:  Manufacturer=Android
       S:  Product=Android
       S:  SerialNumber=0123456789ABCDEF
       C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
       I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
       E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
       E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
       E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      
      WNC D18 LTE CAT3 module (1435:d182)
      
      MI_00 Qualcomm HS-USB Diagnostics
      MI_01 Androd Debug interface
      MI_02 Qualcomm HS-USB Modem
      MI_03 Qualcomm HS-USB NMEA
      MI_04 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_05 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_06 USB Mass Storage Device
      
      ZM8510/ZM8620/ME3960 (19d2:0396)
      
      MI_00 ZTE Mobile Broadband Diagnostics Port
      MI_01 ZTE Mobile Broadband AT Port
      MI_02 ZTE Mobile Broadband Modem
      MI_03 ZTE Mobile Broadband NDIS Port (qmi_wwan)
      MI_04 ZTE Mobile Broadband ADB Port
      
      ME3620_X (19d2:1432)
      
      MI_00 ZTE Diagnostics Device
      MI_01 ZTE UI AT Interface
      MI_02 ZTE Modem Device
      MI_03 ZTE Mobile Broadband Network Adapter
      MI_04 ZTE Composite ADB Interface
      Reported-by: NLars Melin <larsm17@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7341daa0
    • P
      bpf: Fix preempt_enable_no_resched() abuse · c1528193
      Peter Zijlstra 提交于
      [ Upstream commit 0edd6b64d1939e9e9168ff27947995bb7751db5d ]
      
      Unless the very next line is schedule(), or implies it, one must not use
      preempt_enable_no_resched(). It can cause a preemption to go missing and
      thereby cause arbitrary delays, breaking the PREEMPT=y invariant.
      
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c1528193
    • A
      power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUG · aea54f61
      Andrey Smirnov 提交于
      [ Upstream commit 349ced9984ff540ce74ca8a0b2e9b03dc434b9dd ]
      
      Fix a similar endless event loop as was done in commit
      8dcf3217 ("i2c: prevent endless uevent loop with
      CONFIG_I2C_DEBUG_CORE"):
      
        The culprit is the dev_dbg printk in the i2c uevent handler. If
        this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results
        in an endless loop with systemd-journald.
      
        This happens if user-space scans the system log and reads the uevent
        file to get information about a newly created device, which seems
        fair use to me. Unfortunately reading the "uevent" file uses the
        same function that runs for creating the uevent for a new device,
        generating the next syslog entry
      
      Both CONFIG_I2C_DEBUG_CORE and CONFIG_POWER_SUPPLY_DEBUG were reported
      in https://bugs.freedesktop.org/show_bug.cgi?id=76886 but only former
      seems to have been fixed. Drop debug prints as it was done in I2C
      subsystem to resolve the issue.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: linux-pm@vger.kernel.org
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      aea54f61
    • A
      KVM: arm/arm64: Ensure vcpu target is unset on reset failure · a1251522
      Andrew Jones 提交于
      [ Upstream commit 811328fc3222f7b55846de0cd0404339e2e1e6d7 ]
      
      A failed KVM_ARM_VCPU_INIT should not set the vcpu target,
      as the vcpu target is used by kvm_vcpu_initialized() to
      determine if other vcpu ioctls may proceed. We need to set
      the target before calling kvm_reset_vcpu(), but if that call
      fails, we should then unset it and clear the feature bitmap
      while we're at it.
      Signed-off-by: NAndrew Jones <drjones@redhat.com>
      [maz: Simplified patch, completed commit message]
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a1251522
    • K
      net: ieee802154: fix missing checks for regmap_update_bits · 36ae546a
      Kangjie Lu 提交于
      [ Upstream commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4 ]
      
      regmap_update_bits could fail and deserves a check.
      
      The patch adds the checks and if it fails, returns its error
      code upstream.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      36ae546a
    • B
      mac80211: Fix kernel panic due to use of txq after free · 9c045d8c
      Bhagavathi Perumal S 提交于
      [ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
      
      The txq of vif is added to active_txqs list for ATF TXQ scheduling
      in the function ieee80211_queue_skb(), but it was not properly removed
      before freeing the txq object. It was causing use after free of the txq
      objects from the active_txqs list, result was kernel panic
      due to invalid memory access.
      
      Fix kernel invalid memory access by properly removing txq object
      from active_txqs list before free the object.
      Signed-off-by: NBhagavathi Perumal S <bperumal@codeaurora.org>
      Acked-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9c045d8c
    • V
      x86: kvm: hyper-v: deal with buggy TLB flush requests from WS2012 · a0a49d87
      Vitaly Kuznetsov 提交于
      [ Upstream commit da66761c2d93a46270d69001abb5692717495a68 ]
      
      It was reported that with some special Multi Processor Group configuration,
      e.g:
       bcdedit.exe /set groupsize 1
       bcdedit.exe /set maxgroup on
       bcdedit.exe /set groupaware on
      for a 16-vCPU guest WS2012 shows BSOD on boot when PV TLB flush mechanism
      is in use.
      
      Tracing kvm_hv_flush_tlb immediately reveals the issue:
      
       kvm_hv_flush_tlb: processor_mask 0x0 address_space 0x0 flags 0x2
      
      The only flag set in this request is HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES,
      however, processor_mask is 0x0 and no HV_FLUSH_ALL_PROCESSORS is specified.
      We don't flush anything and apparently it's not what Windows expects.
      
      TLFS doesn't say anything about such requests and newer Windows versions
      seem to be unaffected. This all feels like a WS2012 bug, which is, however,
      easy to workaround in KVM: let's flush everything when we see an empty
      flush request, over-flushing doesn't hurt.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a0a49d87
    • L
      PCI: Fix issue with "pci=disable_acs_redir" parameter being ignored · a4696468
      Logan Gunthorpe 提交于
      [ Upstream commit d5bc73f34cc97c4b4b9202cc93182c2515076edf ]
      
      In most cases, kmalloc() will not be available early in boot when
      pci_setup() is called.  Thus, the kstrdup() call that was added to fix the
      __initdata bug with the disable_acs_redir parameter usually returns NULL,
      so the parameter is discarded and has no effect.
      
      To fix this, store the string that's in initdata until an initcall function
      can allocate the memory appropriately.  This way we don't need any
      additional static memory.
      
      Fixes: d2fd6e81912a ("PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter")
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a4696468
    • A
      apparmorfs: fix use-after-free on symlink traversal · b21ca276
      Al Viro 提交于
      [ Upstream commit f51dcd0f621caac5380ce90fbbeafc32ce4517ae ]
      
      symlink body shouldn't be freed without an RCU delay.  Switch apparmorfs
      to ->destroy_inode() and use of call_rcu(); free both the inode and symlink
      body in the callback.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b21ca276
    • A
      securityfs: fix use-after-free on symlink traversal · 9a0467e1
      Al Viro 提交于
      [ Upstream commit 46c874419652bbefdfed17420fd6e88d8a31d9ec ]
      
      symlink body shouldn't be freed without an RCU delay.  Switch securityfs
      to ->destroy_inode() and use of call_rcu(); free both the inode and symlink
      body in the callback.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9a0467e1
    • T
      power: supply: cpcap-battery: Fix division by zero · 900bf351
      Tony Lindgren 提交于
      [ Upstream commit dbe7208c6c4aec083571f2ec742870a0d0edbea3 ]
      
      If called fast enough so samples do not increment, we can get
      division by zero in kernel:
      
      __div0
      cpcap_battery_cc_raw_div
      cpcap_battery_get_property
      power_supply_get_property.part.1
      power_supply_get_property
      power_supply_show_property
      power_supply_uevent
      
      Fixes: 874b2adb ("power: supply: cpcap-battery: Add a battery driver")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      900bf351
    • J
      clk: sunxi-ng: nkmp: Avoid GENMASK(-1, 0) · b7771cb0
      Jernej Skrabec 提交于
      [ Upstream commit 2abc330c514fe56c570bb1a6318b054b06a4f72e ]
      
      Sometimes one of the nkmp factors is unused. This means that one of the
      factors shift and width values are set to 0. Current nkmp clock code
      generates a mask for each factor with GENMASK(width + shift - 1, shift).
      For unused factor this translates to GENMASK(-1, 0). This code is
      further expanded by C preprocessor to final version:
      (((~0UL) - (1UL << (0)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (-1))))
      or a bit simplified:
      (~0UL & (~0UL >> BITS_PER_LONG))
      
      It turns out that result of the second part (~0UL >> BITS_PER_LONG) is
      actually undefined by C standard, which clearly specifies:
      
      "If the value of the right operand is negative or is greater than or
      equal to the width of the promoted left operand, the behavior is
      undefined."
      
      Additionally, compiling kernel with aarch64-linux-gnu-gcc 8.3.0 gave
      different results whether literals or variables with same values as
      literals were used. GENMASK with literals -1 and 0 gives zero and with
      variables gives 0xFFFFFFFFFFFFFFF (~0UL). Because nkmp driver uses
      GENMASK with variables as parameter, expression calculates mask as ~0UL
      instead of 0. This has further consequences that LSB in register is
      always set to 1 (1 is neutral value for a factor and shift is 0).
      
      For example, H6 pll-de clock is set to 600 MHz by sun4i-drm driver, but
      due to this bug ends up being 300 MHz. Additionally, 300 MHz seems to be
      too low because following warning can be found in dmesg:
      
      [    1.752763] WARNING: CPU: 2 PID: 41 at drivers/clk/sunxi-ng/ccu_common.c:41 ccu_helper_wait_for_lock.part.0+0x6c/0x90
      [    1.763378] Modules linked in:
      [    1.766441] CPU: 2 PID: 41 Comm: kworker/2:1 Not tainted 5.1.0-rc2-next-20190401 #138
      [    1.774269] Hardware name: Pine H64 (DT)
      [    1.778200] Workqueue: events deferred_probe_work_func
      [    1.783341] pstate: 40000005 (nZcv daif -PAN -UAO)
      [    1.788135] pc : ccu_helper_wait_for_lock.part.0+0x6c/0x90
      [    1.793623] lr : ccu_helper_wait_for_lock.part.0+0x48/0x90
      [    1.799107] sp : ffff000010f93840
      [    1.802422] x29: ffff000010f93840 x28: 0000000000000000
      [    1.807735] x27: ffff800073ce9d80 x26: ffff000010afd1b8
      [    1.813049] x25: ffffffffffffffff x24: 00000000ffffffff
      [    1.818362] x23: 0000000000000001 x22: ffff000010abd5c8
      [    1.823675] x21: 0000000010000000 x20: 00000000685f367e
      [    1.828987] x19: 0000000000001801 x18: 0000000000000001
      [    1.834300] x17: 0000000000000001 x16: 0000000000000000
      [    1.839613] x15: 0000000000000000 x14: ffff000010789858
      [    1.844926] x13: 0000000000000000 x12: 0000000000000001
      [    1.850239] x11: 0000000000000000 x10: 0000000000000970
      [    1.855551] x9 : ffff000010f936c0 x8 : ffff800074cec0d0
      [    1.860864] x7 : 0000800067117000 x6 : 0000000115c30b41
      [    1.866177] x5 : 00ffffffffffffff x4 : 002c959300bfe500
      [    1.871490] x3 : 0000000000000018 x2 : 0000000029aaaaab
      [    1.876802] x1 : 00000000000002e6 x0 : 00000000686072bc
      [    1.882114] Call trace:
      [    1.884565]  ccu_helper_wait_for_lock.part.0+0x6c/0x90
      [    1.889705]  ccu_helper_wait_for_lock+0x10/0x20
      [    1.894236]  ccu_nkmp_set_rate+0x244/0x2a8
      [    1.898334]  clk_change_rate+0x144/0x290
      [    1.902258]  clk_core_set_rate_nolock+0x180/0x1b8
      [    1.906963]  clk_set_rate+0x34/0xa0
      [    1.910455]  sun8i_mixer_bind+0x484/0x558
      [    1.914466]  component_bind_all+0x10c/0x230
      [    1.918651]  sun4i_drv_bind+0xc4/0x1a0
      [    1.922401]  try_to_bring_up_master+0x164/0x1c0
      [    1.926932]  __component_add+0xa0/0x168
      [    1.930769]  component_add+0x10/0x18
      [    1.934346]  sun8i_dw_hdmi_probe+0x18/0x20
      [    1.938443]  platform_drv_probe+0x50/0xa0
      [    1.942455]  really_probe+0xcc/0x280
      [    1.946032]  driver_probe_device+0x54/0xe8
      [    1.950130]  __device_attach_driver+0x80/0xb8
      [    1.954488]  bus_for_each_drv+0x78/0xc8
      [    1.958326]  __device_attach+0xd4/0x130
      [    1.962163]  device_initial_probe+0x10/0x18
      [    1.966348]  bus_probe_device+0x90/0x98
      [    1.970185]  deferred_probe_work_func+0x6c/0xa0
      [    1.974720]  process_one_work+0x1e0/0x320
      [    1.978732]  worker_thread+0x228/0x428
      [    1.982484]  kthread+0x120/0x128
      [    1.985714]  ret_from_fork+0x10/0x18
      [    1.989290] ---[ end trace 9babd42e1ca4b84f ]---
      
      This commit solves the issue by first checking value of the factor
      width. If it is equal to 0 (unused factor), mask is set to 0, otherwise
      GENMASK() macro is used as before.
      
      Fixes: d897ef56 ("clk: sunxi-ng: Mask nkmp factors when setting register")
      Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
      Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b7771cb0
    • S
      xfrm4: Fix uninitialized memory read in _decode_session4 · a654a73d
      Steffen Klassert 提交于
      [ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
      
      We currently don't reload pointers pointing into skb header
      after doing pskb_may_pull() in _decode_session4(). So in case
      pskb_may_pull() changed the pointers, we read from random
      memory. Fix this by putting all the needed infos on the
      stack, so that we don't need to access the header pointers
      after doing pskb_may_pull().
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a654a73d
    • M
      xfrm: Honor original L3 slave device in xfrmi policy lookup · 6faa6206
      Martin Willi 提交于
      [ Upstream commit 025c65e119bf58b610549ca359c9ecc5dee6a8d2 ]
      
      If an xfrmi is associated to a vrf layer 3 master device,
      xfrm_policy_check() fails after traffic decapsulation. The input
      interface is replaced by the layer 3 master device, and hence
      xfrmi_decode_session() can't match the xfrmi anymore to satisfy
      policy checking.
      
      Extend ingress xfrmi lookup to honor the original layer 3 slave
      device, allowing xfrm interfaces to operate within a vrf domain.
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NMartin Willi <martin@strongswan.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6faa6206
    • S
      esp4: add length check for UDP encapsulation · 3716c262
      Sabrina Dubroca 提交于
      [ Upstream commit 8dfb4eba4100e7cdd161a8baef2d8d61b7a7e62e ]
      
      esp_output_udp_encap can produce a length that doesn't fit in the 16
      bits of a UDP header's length field. In that case, we'll send a
      fragmented packet whose length is larger than IP_MAX_MTU (resulting in
      "Oversized IP packet" warnings on receive) and with a bogus UDP
      length.
      
      To prevent this, add a length check to esp_output_udp_encap and return
       -EMSGSIZE on failure.
      
      This seems to be older than git history.
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3716c262
    • C
      xfrm: clean up xfrm protocol checks · d410ef75
      Cong Wang 提交于
      [ Upstream commit dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399 ]
      
      In commit 6a53b759 ("xfrm: check id proto in validate_tmpl()")
      I introduced a check for xfrm protocol, but according to Herbert
      IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
      it should be removed from validate_tmpl().
      
      And, IPSEC_PROTO_ANY is expected to only match 3 IPSec-specific
      protocols, this is why xfrm_state_flush() could still miss
      IPPROTO_ROUTING, which leads that those entries are left in
      net->xfrm.state_all before exit net. Fix this by replacing
      IPSEC_PROTO_ANY with zero.
      
      This patch also extracts the check from validate_tmpl() to
      xfrm_id_proto_valid() and uses it in parse_ipsecrequest().
      With this, no other protocols should be added into xfrm.
      
      Fixes: 6a53b759 ("xfrm: check id proto in validate_tmpl()")
      Reported-by: syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d410ef75
    • J
      vti4: ipip tunnel deregistration fixes. · 159269cc
      Jeremy Sowden 提交于
      [ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
      
      If tunnel registration failed during module initialization, the module
      would fail to deregister the IPPROTO_COMP protocol and would attempt to
      deregister the tunnel.
      
      The tunnel was not deregistered during module-exit.
      
      Fixes: dd9ee3444014e ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel")
      Signed-off-by: NJeremy Sowden <jeremy@azazel.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      159269cc
    • S
      xfrm6_tunnel: Fix potential panic when unloading xfrm6_tunnel module · 64f214ce
      Su Yanjun 提交于
      [ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
      
      When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
      frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
      xfrm6_tunnel_spi, so need to wait it.
      
      Fixes: 91cc3bb0("xfrm6_tunnel: RCU conversion")
      Signed-off-by: NSu Yanjun <suyj.fnst@cn.fujitsu.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      64f214ce
    • Y
      xfrm: policy: Fix out-of-bound array accesses in __xfrm_policy_unlink · c9516503
      YueHaibing 提交于
      [ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
      
      UBSAN report this:
      
      UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
      index 6 is out of range for type 'unsigned int [6]'
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
       0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
       0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
       ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
      Call Trace:
       <IRQ>  [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
       <IRQ>  [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
       [<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
       [<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
       [<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
       [<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
       [<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
       [<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
       [<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
       [<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
       [<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
       [<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
       [<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
       [<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
       [<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
       [<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
       <EOI>  [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
       [<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
       [<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
       [<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
       [<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
       [<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
       [<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
       [<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
       [<ffffffff8113e119>] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245
      
      The issue is triggered as this:
      
      xfrm_add_policy
          -->verify_newpolicy_info  //check the index provided by user with XFRM_POLICY_MAX
      			      //In my case, the index is 0x6E6BB6, so it pass the check.
          -->xfrm_policy_construct  //copy the user's policy and set xfrm_policy_timer
          -->xfrm_policy_insert
      	--> __xfrm_policy_link //use the orgin dir, in my case is 2
      	--> xfrm_gen_index   //generate policy index, there is 0x6E6BB6
      
      then xfrm_policy_timer be fired
      
      xfrm_policy_timer
         --> xfrm_policy_id2dir  //get dir from (policy index & 7), in my case is 6
         --> xfrm_policy_delete
            --> __xfrm_policy_unlink //access policy_count[dir], trigger out of range access
      
      Add xfrm_policy_id2dir check in verify_newpolicy_info, make sure the computed dir is
      valid, to fix the issue.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: e682adf0 ("xfrm: Try to honor policy index if it's supplied by user")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c9516503
    • K
      fuse: Add FOPEN_STREAM to use stream_open() · fea68500
      Kirill Smelkov 提交于
      commit bbd84f33652f852ce5992d65db4d020aba21f882 upstream.
      
      Starting from commit 9c225f26 ("vfs: atomic f_pos accesses as per
      POSIX") files opened even via nonseekable_open gate read and write via lock
      and do not allow them to be run simultaneously. This can create read vs
      write deadlock if a filesystem is trying to implement a socket-like file
      which is intended to be simultaneously used for both read and write from
      filesystem client.  See commit 10dce8af3422 ("fs: stream_open - opener for
      stream-like files so that read and write can run simultaneously without
      deadlock") for details and e.g. commit 581d21a2 ("xenbus: fix deadlock
      on writes to /proc/xen/xenbus") for a similar deadlock example on
      /proc/xen/xenbus.
      
      To avoid such deadlock it was tempting to adjust fuse_finish_open to use
      stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags,
      but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
      and in particular GVFS which actually uses offset in its read and write
      handlers
      
      	https://codesearch.debian.net/search?q=-%3Enonseekable+%3D
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346
      	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481
      
      so if we would do such a change it will break a real user.
      
      Add another flag (FOPEN_STREAM) for filesystem servers to indicate that the
      opened handler is having stream-like semantics; does not use file position
      and thus the kernel is free to issue simultaneous read and write request on
      opened file handle.
      
      This patch together with stream_open() should be added to stable kernels
      starting from v3.14+. This will allow to patch OSSPD and other FUSE
      filesystems that provide stream-like files to return FOPEN_STREAM |
      FOPEN_NONSEEKABLE in open handler and this way avoid the deadlock on all
      kernel versions. This should work because fuse_finish_open ignores unknown
      open flags returned from a filesystem and so passing FOPEN_STREAM to a
      kernel that is not aware of this flag cannot hurt. In turn the kernel that
      is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE
      is sufficient to implement streams without read vs write deadlock.
      
      Cc: stable@vger.kernel.org # v3.14+
      Signed-off-by: NKirill Smelkov <kirr@nexedi.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fea68500
    • M
      dm mpath: always free attached_handler_name in parse_path() · f9eccf6c
      Martin Wilck 提交于
      commit 940bc471780b004a5277c1931f52af363c2fc9da upstream.
      
      Commit b592211c ("dm mpath: fix attached_handler_name leak and
      dangling hw_handler_name pointer") fixed a memory leak for the case
      where setup_scsi_dh() returns failure. But setup_scsi_dh may return
      success and not "use" attached_handler_name if the
      retain_attached_hwhandler flag is not set on the map. As setup_scsi_sh
      properly "steals" the pointer by nullifying it, freeing it
      unconditionally in parse_path() is safe.
      
      Fixes: b592211c ("dm mpath: fix attached_handler_name leak and dangling hw_handler_name pointer")
      Cc: stable@vger.kernel.org
      Reported-by: NYufen Yu <yuyufen@huawei.com>
      Signed-off-by: NMartin Wilck <mwilck@suse.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9eccf6c
    • M
      dm integrity: correctly calculate the size of metadata area · 9407680a
      Mikulas Patocka 提交于
      commit 30bba430ddf737978e40561198693ba91386dac1 upstream.
      
      When we use separate devices for data and metadata, dm-integrity would
      incorrectly calculate the size of the metadata device as if it had
      512-byte block size - and it would refuse activation with larger block
      size and smaller metadata device.
      
      Fix this so that it takes actual block size into account, which fixes
      the following reported issue:
      https://gitlab.com/cryptsetup/cryptsetup/issues/450
      
      Fixes: 356d9d52 ("dm integrity: allow separate metadata device")
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9407680a
    • M
      dm delay: fix a crash when invalid device is specified · 3b92ff72
      Mikulas Patocka 提交于
      commit 81bc6d150ace6250503b825d9d0c10f7bbd24095 upstream.
      
      When the target line contains an invalid device, delay_ctr() will call
      delay_dtr() with NULL workqueue.  Attempting to destroy the NULL
      workqueue causes a crash.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b92ff72