19 Apr, 2018

23 commits

  • commit 98cf5bbff413eadf1b9cb195a7b80cc61c72a50e upstream.

    The existence test is not being properly logged as the signal mapping
    maps it to the last entry in the named signal table. This is done
    to help catch bugs by making the 0 mapped signal value invalid so
    that we can catch the signal value not being filled in.

    When fixing the off-by-one comparision logic the reporting of the
    existence test was broken, because the logic behind the mapped named
    table was hidden. Fix this by adding a define for the name lookup
    and using it.

    Cc: Stable
    Fixes: f7dc4c9a855a1 ("apparmor: fix off-by-one comparison on MAXMAPPED_SIG")
    Signed-off-by: John Johansen
    Signed-off-by: Greg Kroah-Hartman

    John Johansen
     
  • commit 6d6340672ba3a99c4cf7af79c2edf7aa25595c84 upstream.

    The code that fixes the crashes in the following commit introduced a small
    memory leak:

    commit 6a2cf8d3663e ("scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure")

    Fixing this requires a bit of reworking, which I've explained. Also provide
    some code cleanup.

    There is a small window in qla2x00_probe_one where if qla2x00_alloc_queues
    fails, we end up never freeing req and rsp and leak 0xc0 and 0xc8 bytes
    respectively (the sizes of req and rsp).

    I originally put in checks to test for this condition which were based on
    the incorrect assumption that if ha->rsp_q_map and ha->req_q_map were
    allocated, then rsp and req were allocated as well. This is incorrect.
    There is a window between these allocations:

    ret = qla2x00_mem_alloc(ha, req_length, rsp_length, &req, &rsp);
    goto probe_hw_failed;

    [if successful, both rsp and req allocated]

    base_vha = qla2x00_create_host(sht, ha);
    goto probe_hw_failed;

    ret = qla2x00_request_irqs(ha, rsp);
    goto probe_failed;

    if (qla2x00_alloc_queues(ha, req, rsp)) {
    goto probe_failed;

    [if successful, now ha->rsp_q_map and ha->req_q_map allocated]

    To simplify this, we should just set req and rsp to NULL after we free
    them. Sounds simple enough? The problem is that req and rsp are pointers
    defined in the qla2x00_probe_one and they are not always passed by reference
    to the routines that free them.

    Here are paths which can free req and rsp:

    PATH 1:
    qla2x00_probe_one
    ret = qla2x00_mem_alloc(ha, req_length, rsp_length, &req, &rsp);
    [req and rsp are passed by reference, but if this fails, we currently
    do not NULL out req and rsp. Easily fixed]

    PATH 2:
    qla2x00_probe_one
    failing in qla2x00_request_irqs or qla2x00_alloc_queues
    probe_failed:
    qla2x00_free_device(base_vha);
    qla2x00_free_req_que(ha, req)
    qla2x00_free_rsp_que(ha, rsp)

    PATH 3:
    qla2x00_probe_one:
    failing in qla2x00_mem_alloc or qla2x00_create_host
    probe_hw_failed:
    qla2x00_free_req_que(ha, req)
    qla2x00_free_rsp_que(ha, rsp)

    PATH 1: This should currently work, but it doesn't because rsp and rsp are
    not set to NULL in qla2x00_mem_alloc. Easily remedied.

    PATH 2: req and rsp aren't passed in at all to qla2x00_free_device but are
    derived from ha->req_q_map[0] and ha->rsp_q_map[0]. These are only set up if
    qla2x00_alloc_queues succeeds.

    In qla2x00_free_queues, we are protected from crashing if these don't exist
    because req_qid_map and rsp_qid_map are only set on their allocation. We are
    guarded in this way:

    for (cnt = 0; cnt < ha->max_req_queues; cnt++) {
    if (!test_bit(cnt, ha->req_qid_map))
    continue;

    PATH 3: This works. We haven't freed req or rsp yet (or they were never
    allocated if qla2x00_mem_alloc failed), so we'll attempt to free them here.

    To summarize, there are a few small changes to make this work correctly and
    (and for some cleanup):

    1) (For PATH 1) Set *rsp and *req to NULL in case of failure in
    qla2x00_mem_alloc so these are correctly set to NULL back in
    qla2x00_probe_one

    2) After jumping to probe_failed: and calling qla2x00_free_device,
    explicitly set rsp and req to NULL so further calls with these pointers do
    not crash, i.e. the free queue calls in the probe_hw_failed section we fall
    through to.

    3) Fix return code check in the call to qla2x00_alloc_queues. We currently
    drop the return code on the floor. The probe fails but the caller of the
    probe doesn't have an error code, so it attaches to pci. This can result in
    a crash on module shutdown.

    4) Remove unnecessary NULL checks in qla2x00_free_req_que,
    qla2x00_free_rsp_que, and the egregious NULL checks before kfrees and vfrees
    in qla2x00_mem_free.

    I tested this out running a scenario where the card breaks at various times
    during initialization. I made sure I forced every error exit path in
    qla2x00_probe_one.

    Cc: # v4.16
    Fixes: 6a2cf8d3663e ("scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure")
    Signed-off-by: Bill Kuzeja
    Acked-by: Himanshu Madhani
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Greg Kroah-Hartman

    Bill Kuzeja
     
  • commit 11cf887728a3d1de77cc12ce247b64ef32608891 upstream.

    Scalable MCA systems have various types of banks. The bank's type
    can determine how we handle errors from it. For example, if a bank
    represents a UMC (Unified Memory Controller) then we will need to
    convert its address from a normalized address to a system physical
    address before handling the error.

    [ bp: Verify m->bank is within range and use bank pointer. ]

    Signed-off-by: Yazen Ghannam
    Signed-off-by: Borislav Petkov
    Signed-off-by: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20171207203955.118171-1-Yazen.Ghannam@amd.com
    Signed-off-by: Greg Kroah-Hartman

    Yazen Ghannam
     
  • commit c02216acf4177c4411d33735c81cad687790fa59 upstream.

    In randconfig testing, we sometimes get this warning:

    drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
    drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]
    #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \

    This is rather annoying since almost all other code produces no build-time
    output unless we have found a real bug. We already fixed this in the
    amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
    compile testing") by adding a CONFIG_COMPILE_TEST check last year and
    agreed to do the same here, but both Michel and I then forgot about it
    until I came across the issue again now.

    For stable kernels, as this is one of very few remaining randconfig
    warnings in 4.14.

    Cc: stable@vger.kernel.org
    Link: https://patchwork.kernel.org/patch/9550009/
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Michel Dänzer
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     
  • commit 621b6d2ea297d0fb6030452c5bcd221f12165fcf upstream.

    A use-after-free bug was caught by KASAN while running usdt related
    code (BCC project. bcc/tests/python/test_usdt2.py):

    ==================================================================
    BUG: KASAN: use-after-free in uprobe_perf_close+0x222/0x3b0
    Read of size 4 at addr ffff880384f9b4a4 by task test_usdt2.py/870

    CPU: 4 PID: 870 Comm: test_usdt2.py Tainted: G W 4.16.0-next-20180409 #215
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    Call Trace:
    dump_stack+0xc7/0x15b
    ? show_regs_print_info+0x5/0x5
    ? printk+0x9c/0xc3
    ? kmsg_dump_rewind_nolock+0x6e/0x6e
    ? uprobe_perf_close+0x222/0x3b0
    print_address_description+0x83/0x3a0
    ? uprobe_perf_close+0x222/0x3b0
    kasan_report+0x1dd/0x460
    ? uprobe_perf_close+0x222/0x3b0
    uprobe_perf_close+0x222/0x3b0
    ? probes_open+0x180/0x180
    ? free_filters_list+0x290/0x290
    trace_uprobe_register+0x1bb/0x500
    ? perf_event_attach_bpf_prog+0x310/0x310
    ? probe_event_disable+0x4e0/0x4e0
    perf_uprobe_destroy+0x63/0xd0
    _free_event+0x2bc/0xbd0
    ? lockdep_rcu_suspicious+0x100/0x100
    ? ring_buffer_attach+0x550/0x550
    ? kvm_sched_clock_read+0x1a/0x30
    ? perf_event_release_kernel+0x3e4/0xc00
    ? __mutex_unlock_slowpath+0x12e/0x540
    ? wait_for_completion+0x430/0x430
    ? lock_downgrade+0x3c0/0x3c0
    ? lock_release+0x980/0x980
    ? do_raw_spin_trylock+0x118/0x150
    ? do_raw_spin_unlock+0x121/0x210
    ? do_raw_spin_trylock+0x150/0x150
    perf_event_release_kernel+0x5d4/0xc00
    ? put_event+0x30/0x30
    ? fsnotify+0xd2d/0xea0
    ? sched_clock_cpu+0x18/0x1a0
    ? __fsnotify_update_child_dentry_flags.part.0+0x1b0/0x1b0
    ? pvclock_clocksource_read+0x152/0x2b0
    ? pvclock_read_flags+0x80/0x80
    ? kvm_sched_clock_read+0x1a/0x30
    ? sched_clock_cpu+0x18/0x1a0
    ? pvclock_clocksource_read+0x152/0x2b0
    ? locks_remove_file+0xec/0x470
    ? pvclock_read_flags+0x80/0x80
    ? fcntl_setlk+0x880/0x880
    ? ima_file_free+0x8d/0x390
    ? lockdep_rcu_suspicious+0x100/0x100
    ? ima_file_check+0x110/0x110
    ? fsnotify+0xea0/0xea0
    ? kvm_sched_clock_read+0x1a/0x30
    ? rcu_note_context_switch+0x600/0x600
    perf_release+0x21/0x40
    __fput+0x264/0x620
    ? fput+0xf0/0xf0
    ? do_raw_spin_unlock+0x121/0x210
    ? do_raw_spin_trylock+0x150/0x150
    ? SyS_fchdir+0x100/0x100
    ? fsnotify+0xea0/0xea0
    task_work_run+0x14b/0x1e0
    ? task_work_cancel+0x1c0/0x1c0
    ? copy_fd_bitmaps+0x150/0x150
    ? vfs_read+0xe5/0x260
    exit_to_usermode_loop+0x17b/0x1b0
    ? trace_event_raw_event_sys_exit+0x1a0/0x1a0
    do_syscall_64+0x3f6/0x490
    ? syscall_return_slowpath+0x2c0/0x2c0
    ? lockdep_sys_exit+0x1f/0xaa
    ? syscall_return_slowpath+0x1a3/0x2c0
    ? lockdep_sys_exit+0x1f/0xaa
    ? prepare_exit_to_usermode+0x11c/0x1e0
    ? enter_from_user_mode+0x30/0x30
    random: crng init done
    ? __put_user_4+0x1c/0x30
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x7f41d95f9340
    RSP: 002b:00007fffe71e4268 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
    RAX: 0000000000000000 RBX: 000000000000000d RCX: 00007f41d95f9340
    RDX: 0000000000000000 RSI: 0000000000002401 RDI: 000000000000000d
    RBP: 0000000000000000 R08: 00007f41ca8ff700 R09: 00007f41d996dd1f
    R10: 00007fffe71e41e0 R11: 0000000000000246 R12: 00007fffe71e4330
    R13: 0000000000000000 R14: fffffffffffffffc R15: 00007fffe71e4290

    Allocated by task 870:
    kasan_kmalloc+0xa0/0xd0
    kmem_cache_alloc_node+0x11a/0x430
    copy_process.part.19+0x11a0/0x41c0
    _do_fork+0x1be/0xa20
    do_syscall_64+0x198/0x490
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2

    Freed by task 0:
    __kasan_slab_free+0x12e/0x180
    kmem_cache_free+0x102/0x4d0
    free_task+0xfe/0x160
    __put_task_struct+0x189/0x290
    delayed_put_task_struct+0x119/0x250
    rcu_process_callbacks+0xa6c/0x1b60
    __do_softirq+0x238/0x7ae

    The buggy address belongs to the object at ffff880384f9b480
    which belongs to the cache task_struct of size 12928

    It occurs because task_struct is freed before perf_event which refers
    to the task and task flags are checked while teardown of the event.
    perf_event_alloc() assigns task_struct to hw.target of perf_event,
    but there is no reference counting for it.

    As a fix we get_task_struct() in perf_event_alloc() at above mentioned
    assignment and put_task_struct() in _free_event().

    Signed-off-by: Prashant Bhole
    Reviewed-by: Oleg Nesterov
    Acked-by: Peter Zijlstra (Intel)
    Cc:
    Cc: Alexander Shishkin
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Linus Torvalds
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 63b6da39bb38e8f1a1ef3180d32a39d6 ("perf: Fix perf_event_exit_task() race")
    Link: http://lkml.kernel.org/r/20180409100346.6416-1-bhole_prashant_q7@lab.ntt.co.jp
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Prashant Bhole
     
  • commit 91d29b288aed3406caf7c454bf2b898c96cfd177 upstream.

    timestamp_insn_cnt is used to estimate the timestamp based on the number of
    instructions since the last known timestamp.

    If the estimate is not accurate enough decoding might not be correctly
    synchronized with side-band events causing more trace errors.

    However there are always timestamps following an overflow, so the
    estimate is not needed and can indeed result in more errors.

    Suppress the estimate by setting timestamp_insn_cnt to zero.

    Signed-off-by: Adrian Hunter
    Cc: Jiri Olsa
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1520431349-30689-5-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Adrian Hunter
     
  • commit 1c196a6c771c47a2faa63d38d913e03284f73a16 upstream.

    When a TIP packet is expected but there is a different packet, it is an
    error. However the unexpected packet might be something important like a
    TSC packet, so after the error, it is necessary to continue from there,
    rather than the next packet. That is achieved by setting pkt_step to
    zero.

    Signed-off-by: Adrian Hunter
    Cc: Jiri Olsa
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1520431349-30689-4-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Adrian Hunter
     
  • commit 63d8e38f6ae6c36dd5b5ba0e8c112e8861532ea2 upstream.

    sync_switch is a facility to synchronize decoding more closely with the
    point in the kernel when the context actually switched.

    The flag when sync_switch is enabled was global to the decoding, whereas
    it is really specific to the CPU.

    The trace data for different CPUs is put on different queues, so add
    sync_switch to the intel_pt_queue structure and use that in preference
    to the global setting in the intel_pt structure.

    That fixes problems decoding one CPU's trace because sync_switch was
    disabled on a different CPU's queue.

    Signed-off-by: Adrian Hunter
    Cc: Jiri Olsa
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1520431349-30689-3-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Adrian Hunter
     
  • commit 117db4b27bf08dba412faf3924ba55fe970c57b8 upstream.

    Overlap detection was not not updating the buffer's 'consecutive' flag.
    Marking buffers consecutive has the advantage that decoding begins from
    the start of the buffer instead of the first PSB. Fix overlap detection
    to identify consecutive buffers correctly.

    Signed-off-by: Adrian Hunter
    Cc: Jiri Olsa
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1520431349-30689-2-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Adrian Hunter
     
  • commit 19ce7909ed11c49f7eddf59e7f49cd3062bf83d5 upstream.

    This crashes with a "Bad real address for load" attempting to load
    from the vmalloc region in realmode (faulting address is in DAR).

    Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
    LE SMP NR_CPUS=2048 NUMA PowerNV
    CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994
    NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
    REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994)
    MSR: 9000000000201003 CR: 48082222 XER: 00000000
    CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
    NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
    LR [c0000000000c2430] do_tlbies+0x230/0x2f0

    I suspect the reason is the per-cpu data is not in the linear chunk.
    This could be restored if that was able to be fixed, but for now,
    just remove the tracepoints.

    Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions")
    Cc: stable@vger.kernel.org # v4.13+
    Signed-off-by: Nicholas Piggin
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Piggin
     
  • commit 021ad274d7dc31611d4f47f7dd4ac7a224526f30 upstream.

    When we hot-remove the device, we first receive a PCI_EJECT message and
    then receive a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.

    The first message is offloaded to hv_eject_device_work(), and the second
    is offloaded to pci_devices_present_work(). Both the paths can be running
    list_del(&hpdev->list_entry), causing general protection fault, because
    system_wq can run them concurrently.

    The patch eliminates the race condition.

    Since access to present/eject work items is serialized, we do not need the
    hbus->enum_sem anymore, so remove it.

    Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
    Link: https://lkml.kernel.org/r/KL1P15301MB00064DA6B4D221123B5241CFBFD70@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM
    Tested-by: Adrian Suhov
    Tested-by: Chris Valean
    Signed-off-by: Dexuan Cui
    [lorenzo.pieralisi@arm.com: squashed semaphore removal patch]
    Signed-off-by: Lorenzo Pieralisi
    Reviewed-by: Michael Kelley
    Acked-by: Haiyang Zhang
    Cc: # v4.6+
    Cc: Vitaly Kuznetsov
    Cc: Jack Morgenstein
    Cc: Stephen Hemminger
    Cc: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Dexuan Cui
     
  • commit 238064f13d057390a8c5e1a6a80f4f0a0ec46499 upstream.

    The pci-hyperv driver's channel callback hv_pci_onchannelcallback() is not
    really a hot path, so we don't need to mark it as a perf_device, meaning
    with this patch all HV_PCIE channels' target_cpu will be CPU0.

    Signed-off-by: Dexuan Cui
    Cc: stable@vger.kernel.org
    Cc: Stephen Hemminger
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Dexuan Cui
     
  • commit d5654e156bc4d68a87bbaa6d7e020baceddf6e68 upstream.

    Make sure that the HPMC (High Priority Machine Check) handler is 16-byte
    aligned and that it's length in the IVT is a multiple of 16 bytes.
    Otherwise PDC may decide not to call the HPMC crash handler.

    Signed-off-by: Helge Deller
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Helge Deller
     
  • commit 615b2665fd20c327b631ff1e79426775de748094 upstream.

    As found by the ubsan checker, the value of the 'index' variable can be
    out of range for the bc[] array:

    UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21
    index 6 is out of range for type 'char [6]'
    Backtrace:
    [] __ubsan_handle_out_of_bounds+0x68/0x80
    [] check_parent+0xc0/0x170
    [] descend_children+0x30/0x6c
    [] device_for_each_child+0x60/0x98
    [] parse_tree_node+0x40/0x54
    [] check_parent+0xf0/0x170
    [] descend_children+0x30/0x6c
    [] device_for_each_child+0x60/0x98
    [] descend_children+0x4c/0x6c
    [] device_for_each_child+0x60/0x98
    [] parse_tree_node+0x40/0x54
    [] hwpath_to_device+0xa4/0xc4

    Signed-off-by: Helge Deller
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Helge Deller
     
  • commit 613928e85317b945c863bb893f5737d2f22f5425 upstream.

    To allow dual pipelines utilising two WPF entities when available, the
    VSP was updated to support header-mode display list in continuous
    pipelines.

    A small bug in the status check of the command register causes the
    second pipeline to be directly afflicted by the running of the first;
    appearing as a perceived performance issue with stuttering display.

    Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
    comparison corresponds to the correct pipeline.

    Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display lists in continuous mode")

    Cc: "Stable v4.14+"
    Signed-off-by: Kieran Bingham
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Kieran Bingham
     
  • commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

    At put_v4l2_window32(), it tries to access kp->clips. However,
    kp points to an userspace pointer. So, it should be obtained
    via get_user(), otherwise it can OOPS:

    vivid-000: ================== END STATUS ==================
    BUG: unable to handle kernel paging request at 00000000fffb18e0
    IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
    PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 800000042548f067
    Oops: 0001 [#1] SMP
    Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich video crc32c_intel [last unloaded: media]
    CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
    Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
    task: ffff8804293f8000 ti: ffff8803f5640000 task.ti: ffff8803f5640000
    RIP: 0010:[] [] __put_v4l2_format32+0x169/0x220 [videodev]
    RSP: 0018:ffff8803f5643e28 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffb1ab4
    RDX: 00000000fffb1a68 RSI: 00000000fffb18d8 RDI: 00000000fffb1aa8
    RBP: ffff8803f5643e48 R08: 0000000000000001 R09: ffff8803f54b0378
    R10: 0000000000000000 R11: 0000000000000168 R12: 00000000fffb18c0
    R13: 00000000fffb1a94 R14: 00000000fffb18c8 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffff880456d00000(0063) knlGS:00000000f7100980
    CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 00000000fffb18e0 CR3: 00000003f552b000 CR4: 00000000003407e0
    Stack:
    00000000fffb1a94 00000000c0cc5640 0000000000000056 ffff8804274f3600
    ffff8803f5643ed0 ffffffffc0547e16 0000000000000003 ffff8803f5643eb0
    ffffffff81301460 ffff88009db44b01 ffff880441942520 ffff8800c0d05640
    Call Trace:
    [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
    [] ? file_has_perm+0x70/0xc0
    [] compat_SyS_ioctl+0xec/0x1200
    [] sysenter_dispatch+0x7/0x21
    Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff 8b 64 24 20 41 89 d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
    RIP [] __put_v4l2_format32+0x169/0x220 [videodev]
    RSP
    CR2: 00000000fffb18e0

    Tested with vivid driver on Kernel v3.18.102.

    Same bug happens upstream too:

    BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
    Read of size 8 at addr 00000000ffe48400 by task v4l2-compliance/8713

    CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
    Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
    Call Trace:
    dump_stack+0x5c/0x7c
    kasan_report+0x164/0x380
    ? __put_v4l2_format32+0x98/0x4d0 [videodev]
    __put_v4l2_format32+0x98/0x4d0 [videodev]
    v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
    ? __fsnotify_inode_delete+0x20/0x20
    ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
    compat_SyS_ioctl+0x646/0x14d0
    ? do_ioctl+0x30/0x30
    do_fast_syscall_32+0x191/0x3f4
    entry_SYSENTER_compat+0x6b/0x7a
    ==================================================================
    Disabling lock debugging due to kernel taint
    BUG: unable to handle kernel paging request at 00000000ffe48400
    IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
    PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 80000003256af067
    Oops: 0001 [#1] SMP KASAN
    Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer intel_rapl_perf
    drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
    CPU: 0 PID: 8713 Comm: v4l2-compliance Tainted: G B 4.16.0-rc4+ #108
    Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
    RIP: 0010:__put_v4l2_format32+0x98/0x4d0 [videodev]
    RSP: 0018:ffff8803b9be7d30 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8803ac983e80 RCX: ffffffff8cd929f2
    RDX: 1ffffffff1d0a149 RSI: 0000000000000297 RDI: 0000000000000297
    RBP: 00000000ffe485c0 R08: fffffbfff1cf5123 R09: ffffffff8e7a8948
    R10: 0000000000000001 R11: fffffbfff1cf5122 R12: 00000000ffe483e0
    R13: 00000000ffe485c4 R14: ffff8803ac985918 R15: 00000000ffe483e8
    FS: 0000000000000000(0000) GS:ffff880407400000(0063) knlGS:00000000f7a46980
    CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 00000000ffe48400 CR3: 00000003a83f2003 CR4: 00000000003606f0
    Call Trace:
    v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
    ? __fsnotify_inode_delete+0x20/0x20
    ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
    compat_SyS_ioctl+0x646/0x14d0
    ? do_ioctl+0x30/0x30
    do_fast_syscall_32+0x191/0x3f4
    entry_SYSENTER_compat+0x6b/0x7a
    Code: 4c 89 f7 4d 8d 7c 24 08 e8 e6 a4 69 cb 48 8b 83 98 1a 00 00 48 83 e8 10 49 39 c7 0f 87 9d 01 00 00 49 8d 7c 24 20 e8 c8 a4 69 cb 8b 74 24 20 4c 89 ef 4c 89 fe ba 10 00 00 00 e8 23 d9 08 cc
    RIP: __put_v4l2_format32+0x98/0x4d0 [videodev] RSP: ffff8803b9be7d30
    CR2: 00000000ffe48400

    cc: stable@vger.kernel.org
    Signed-off-by: Mauro Carvalho Chehab
    Reviewed-by: Sakari Ailus
    Reviewed-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Mauro Carvalho Chehab
     
  • [ Upstream commit 4bfc33807a9a02764bdd1e42e794b3b401240f27 ]

    lan78xx_read_otp tries to return -EINVAL in the event of invalid OTP
    content, but the value gets overwritten before it is returned and the
    read goes ahead anyway. Make the read conditional as it should be
    and preserve the error code.

    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Signed-off-by: Phil Elwell
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Phil Elwell
     
  • [ Upstream commit 7ced6c98c7ab7a1f6743931e28671b833af79b1e ]

    vhost_copy_to_user is used to copy vring used elements to userspace.
    We should use VHOST_ADDR_USED instead of VHOST_ADDR_DESC.

    Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache")
    Signed-off-by: Eric Auger
    Acked-by: Jason Wang
    Acked-by: Michael S. Tsirkin
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eric Auger
     
  • [ Upstream commit d14d2b78090c7de0557362b26a4ca591aa6a9faa ]

    Commit d65026c6c62e7d9616c8ceb5a53b68bcdc050525 ("vhost: validate log
    when IOTLB is enabled") introduced a regression. The logic was
    originally:

    if (vq->iotlb)
    return 1;
    return A && B;

    After the patch the short-circuit logic for A was inverted:

    if (A || vq->iotlb)
    return A;
    return B;

    This patch fixes the regression by rewriting the checks in the obvious
    way, no longer returning A when vq->iotlb is non-NULL (which is hard to
    understand).

    Reported-by: syzbot+65a84dde0214b0387ccd@syzkaller.appspotmail.com
    Cc: Jason Wang
    Signed-off-by: Stefan Hajnoczi
    Acked-by: Michael S. Tsirkin
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Stefan Hajnoczi
     
  • [ Upstream commit 3f01ddb962dc506916c243f9524e8bef97119b77 ]

    On receiving a packet the state index points to the rstate which must be
    used to fill up IP and TCP headers. But if the state index points to a
    rstate which is unitialized, i.e. filled with zeros, it gets stuck in an
    infinite loop inside ip_fast_csum trying to compute the ip checsum of a
    header with zero length.

    89.666953: [] slhc_uncompress+0x464/0x468
    89.666965: [] ppp_receive_nonmp_frame+0x3b4/0x65c
    89.666978: [] ppp_receive_frame+0x64/0x7e0
    89.666991: [] ppp_input+0x104/0x198
    89.667005: [] pppopns_recv_core+0x238/0x370
    89.667027: [] __sk_receive_skb+0xdc/0x250
    89.667040: [] pppopns_recv+0x44/0x60
    89.667053: [] __sock_queue_rcv_skb+0x16c/0x24c
    89.667065: [] sock_queue_rcv_skb+0x2c/0x38
    89.667085: [] raw_rcv+0x124/0x154
    89.667098: [] raw_local_deliver+0x1e0/0x22c
    89.667117: [] ip_local_deliver_finish+0x70/0x24c
    89.667131: [] ip_local_deliver+0x100/0x10c

    ./scripts/faddr2line vmlinux slhc_uncompress+0x464/0x468 output:
    ip_fast_csum at arch/arm64/include/asm/checksum.h:40
    (inlined by) slhc_uncompress at drivers/net/slip/slhc.c:615

    Adding a variable to indicate if the current rstate is initialized. If
    such a packet arrives, move to toss state.

    Signed-off-by: Tejaswi Tanikella
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Tejaswi Tanikella
     
  • [ Upstream commit a43cced9a348901f9015f4730b70b69e7c41a9c9 ]

    rds_sendmsg() calls rds_send_mprds_hash() to find a c_path to use to
    send a message. Suppose the RDS connection is not yet up. In
    rds_send_mprds_hash(), it does

    if (conn->c_npaths == 0)
    wait_event_interruptible(conn->c_hs_waitq,
    (conn->c_npaths != 0));

    If it is interrupted before the connection is set up,
    rds_send_mprds_hash() will return a non-zero hash value. Hence
    rds_sendmsg() will use a non-zero c_path to send the message. But if
    the RDS connection ends up to be non-MP capable, the message will be
    lost as only the zero c_path can be used.

    Signed-off-by: Ka-Cheong Poon
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Ka-Cheong Poon
     
  • [ Upstream commit 53765341ee821c0a0f1dec41adc89c9096ad694c ]

    The Cinterion AHS8 is a 3G device with one embedded WWAN interface
    using cdc_ether as a driver.

    The modem is controlled via AT commands through the exposed TTYs.

    AT+CGDCONT write command can be used to activate or deactivate a WWAN
    connection for a PDP context defined with the same command. UE
    supports one WWAN adapter.

    Signed-off-by: Bassem Boubaker
    Acked-by: Oliver Neukum
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Bassem Boubaker
     
  • commit f998b6b10144cd9809da6af02758615f789e8aa1 upstream.

    Patch "netfilter: ipset: use nfnl_mutex_is_locked" is added the real
    mutex locking check, which revealed the missing locking in ip_set_net_exit().

    Signed-off-by: Jozsef Kadlecsik
    Reported-by: syzbot+36b06f219f2439fe62e1@syzkaller.appspotmail.com
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Greg Kroah-Hartman

    Jozsef Kadlecsik
     

12 Apr, 2018

17 commits

  • Greg Kroah-Hartman
     
  • [ Upstream commit 461d5f1b59490ce0096dfda45e10038c122a7892 ]

    mlx4_delete_all_resources_for_slave in resource tracker should free all
    memory allocated for a slave.
    While releasing memory of fs_rule, it misses releasing memory of
    fs_rule->mirr_mbox.

    Fixes: 78efed275117 ('net/mlx4_core: Support mirroring VF DMFS rules on both ports')
    Signed-off-by: Moshe Shemesh
    Signed-off-by: Tariq Toukan
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Moshe Shemesh
     
  • [ Upstream commit aaa3149bbee9ba9b4e6f0bd6e3e7d191edeae942 ]

    We try to hold TX virtqueue mutex in vhost_net_rx_peek_head_len()
    after RX virtqueue mutex is held in handle_rx(). This requires an
    appropriate lock nesting notation to calm down deadlock detector.

    Fixes: 0308813724606 ("vhost_net: basic polling support")
    Reported-by: syzbot+7f073540b1384a614e09@syzkaller.appspotmail.com
    Signed-off-by: Jason Wang
    Acked-by: Michael S. Tsirkin
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jason Wang
     
  • [ Upstream commit 982cf3b3999d39a2eaca0a65542df33c19b5d814 ]

    The same fix as in 'bonding: move dev_mc_sync after master_upper_dev_link
    in bond_enslave' is needed for team driver.

    The panic can be reproduced easily:

    ip link add team1 type team
    ip link set team1 up
    ip link add link team1 vlan1 type vlan id 80
    ip link set vlan1 master team1

    Fixes: cb41c997d444 ("team: team should sync the port's uc/mc addrs when add a port")
    Signed-off-by: Xin Long
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     
  • [ Upstream commit 6174a30df1b902e1fedbd728f5343937e83e64e6 ]

    Prior to this patch, when one packet is hashed into path [1]
    (hash
    Signed-off-by: Xin Long
    Acked-by: David Ahern
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Xin Long
     
  • [ Upstream commit d65026c6c62e7d9616c8ceb5a53b68bcdc050525 ]

    Vq log_base is the userspace address of bitmap which has nothing to do
    with IOTLB. So it needs to be validated unconditionally otherwise we
    may try use 0 as log_base which may lead to pin pages that will lead
    unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).

    Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
    Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
    Signed-off-by: Jason Wang
    Acked-by: Michael S. Tsirkin
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jason Wang
     
  • [ Upstream commit 4246f698dd58e3c6246fa919ef0b0a1d29a57e4a ]

    Increase representor netdev RQ size to avoid dropped packets.
    The current size (two) is just too small to keep up with
    conventional slow path traffic patterns.
    Also match the SQ size to the RQ size.

    Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
    Signed-off-by: Roi Dayan
    Reviewed-by: Paul Blakey
    Reviewed-by: Or Gerlitz
    Signed-off-by: Saeed Mahameed
    Signed-off-by: Greg Kroah-Hartman

    Roi Dayan
     
  • [ Upstream commit 6e8814ceb7e8f468659ef9253bd212c07ae19584 ]

    Global pause and PFC configuration should be mutually exclusive (i.e. only
    one of them at most can be set). However, once PFC was turned off,
    driver automatically turned Global pause on. This is a bug.

    Fix the driver behaviour to turn off PFC/Global once the user turned the
    other on.

    This also fixed a weird behaviour that at a current time, the profile
    had both PFC and global pause configuration turned on, which is
    Hardware-wise impossible and caused returning false positive indication
    to query tools.

    In addition, fix error code when setting global pause or PFC to change
    metadata only upon successful change.

    Also, removed useless debug print.

    Fixes: af7d51852631 ("net/mlx4_en: Add DCB PFC support through CEE netlink commands")
    Fixes: c27a02cd94d6 ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
    Signed-off-by: Eran Ben Elisha
    Signed-off-by: Tariq Toukan
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eran Ben Elisha
     
  • [ Upstream commit cd00edc179863848abab5cc5683de5b7b5f70954 ]

    strp_parser_err is called with a negative code everywhere, which then
    calls abort_parser with a negative code. strp_msg_timeout calls
    abort_parser directly with a positive code. Negate ETIMEDOUT
    to match signed-ness of other calls.

    The default abort_parser callback, strp_abort_strp, sets
    sk->sk_err to err. Also negate the error here so sk_err always
    holds a positive value, as the rest of the net code expects. Currently
    a negative sk_err can result in endless loops, or user code that
    thinks it actually sent/received err bytes.

    Found while testing net/tls_sw recv path.

    Fixes: 43a0c6751a322847 ("strparser: Stream parser for messages")
    Signed-off-by: Dave Watson
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Dave Watson
     
  • [ Upstream commit 2d433610176d6569e8b3a28f67bc72235bf69efc ]

    when the following command

    # tc action replace action skbmod swap mac index 100

    is run for the first time, and tcf_skbmod_init() fails to allocate struct
    tcf_skbmod_params, tcf_skbmod_cleanup() calls kfree_rcu(NULL), thus
    causing the following error:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    IP: __call_rcu+0x23/0x2b0
    PGD 8000000034057067 P4D 8000000034057067 PUD 74937067 PMD 0
    Oops: 0002 [#1] SMP PTI
    Modules linked in: act_skbmod(E) psample ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 snd_hda_codec_generic snd_hda_intel snd_hda_codec crct10dif_pclmul mbcache jbd2 crc32_pclmul snd_hda_core ghash_clmulni_intel snd_hwdep pcbc snd_seq snd_seq_device snd_pcm aesni_intel snd_timer crypto_simd glue_helper snd cryptd virtio_balloon joydev soundcore pcspkr i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_console virtio_net virtio_blk ata_piix libata crc32c_intel virtio_pci serio_raw virtio_ring virtio i2c_core floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_skbmod]
    CPU: 3 PID: 3144 Comm: tc Tainted: G E 4.16.0-rc4.act_vlan.orig+ #403
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    RIP: 0010:__call_rcu+0x23/0x2b0
    RSP: 0018:ffffbd2e403e7798 EFLAGS: 00010246
    RAX: ffffffffc0872080 RBX: ffff981d34bff780 RCX: 00000000ffffffff
    RDX: ffffffff922a5f00 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000021f
    R10: 000000003d003000 R11: 0000000000aaaaaa R12: 0000000000000000
    R13: ffffffff922a5f00 R14: 0000000000000001 R15: ffff981d3b698c2c
    FS: 00007f3678292740(0000) GS:ffff981d3fd80000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 000000007c57a006 CR4: 00000000001606e0
    Call Trace:
    __tcf_idr_release+0x79/0xf0
    tcf_skbmod_init+0x1d1/0x210 [act_skbmod]
    tcf_action_init_1+0x2cc/0x430
    tcf_action_init+0xd3/0x1b0
    tc_ctl_action+0x18b/0x240
    rtnetlink_rcv_msg+0x29c/0x310
    ? _cond_resched+0x15/0x30
    ? __kmalloc_node_track_caller+0x1b9/0x270
    ? rtnl_calcit.isra.28+0x100/0x100
    netlink_rcv_skb+0xd2/0x110
    netlink_unicast+0x17c/0x230
    netlink_sendmsg+0x2cd/0x3c0
    sock_sendmsg+0x30/0x40
    ___sys_sendmsg+0x27a/0x290
    ? filemap_map_pages+0x34a/0x3a0
    ? __handle_mm_fault+0xbfd/0xe20
    __sys_sendmsg+0x51/0x90
    do_syscall_64+0x6e/0x1a0
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x7f36776a3ba0
    RSP: 002b:00007fff4703b618 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007fff4703b740 RCX: 00007f36776a3ba0
    RDX: 0000000000000000 RSI: 00007fff4703b690 RDI: 0000000000000003
    RBP: 000000005aaaba36 R08: 0000000000000002 R09: 0000000000000000
    R10: 00007fff4703b0a0 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fff4703b754 R14: 0000000000000001 R15: 0000000000669f60
    Code: 5d e9 42 da ff ff 66 90 0f 1f 44 00 00 41 57 41 56 41 55 49 89 d5 41 54 55 48 89 fd 53 48 83 ec 08 40 f6 c7 07 0f 85 19 02 00 00 89 75 08 48 c7 45 00 00 00 00 00 9c 58 0f 1f 44 00 00 49 89
    RIP: __call_rcu+0x23/0x2b0 RSP: ffffbd2e403e7798
    CR2: 0000000000000008

    Fix it in tcf_skbmod_cleanup(), ensuring that kfree_rcu(p, ...) is called
    only when p is not NULL.

    Fixes: 86da71b57383 ("net_sched: Introduce skbmod action")
    Signed-off-by: Davide Caratti
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Davide Caratti
     
  • [ Upstream commit abdadd3cfd3e7ea3da61ac774f84777d1f702058 ]

    when the following command

    # tc action add action tunnel_key unset index 100

    is run for the first time, and tunnel_key_init() fails to allocate struct
    tcf_tunnel_key_params, tunnel_key_release() dereferences NULL pointers.
    This causes the following error:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    IP: tunnel_key_release+0xd/0x40 [act_tunnel_key]
    PGD 8000000033787067 P4D 8000000033787067 PUD 74646067 PMD 0
    Oops: 0000 [#1] SMP PTI
    Modules linked in: act_tunnel_key(E) act_csum ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel pcbc snd_hda_codec snd_hda_core snd_hwdep snd_seq aesni_intel snd_seq_device crypto_simd glue_helper snd_pcm cryptd joydev snd_timer pcspkr virtio_balloon snd i2c_piix4 soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_net virtio_blk drm virtio_console crc32c_intel ata_piix serio_raw i2c_core virtio_pci libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
    CPU: 2 PID: 3101 Comm: tc Tainted: G E 4.16.0-rc4.act_vlan.orig+ #403
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    RIP: 0010:tunnel_key_release+0xd/0x40 [act_tunnel_key]
    RSP: 0018:ffffba46803b7768 EFLAGS: 00010286
    RAX: ffffffffc09010a0 RBX: 0000000000000000 RCX: 0000000000000024
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff99ee336d7480
    RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
    R10: 0000000000000220 R11: ffff99ee79d73131 R12: 0000000000000000
    R13: ffff99ee32d67610 R14: ffff99ee7671dc38 R15: 00000000fffffff4
    FS: 00007febcb2cd740(0000) GS:ffff99ee7fd00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000010 CR3: 000000007c8e4005 CR4: 00000000001606e0
    Call Trace:
    __tcf_idr_release+0x79/0xf0
    tunnel_key_init+0xd9/0x460 [act_tunnel_key]
    tcf_action_init_1+0x2cc/0x430
    tcf_action_init+0xd3/0x1b0
    tc_ctl_action+0x18b/0x240
    rtnetlink_rcv_msg+0x29c/0x310
    ? _cond_resched+0x15/0x30
    ? __kmalloc_node_track_caller+0x1b9/0x270
    ? rtnl_calcit.isra.28+0x100/0x100
    netlink_rcv_skb+0xd2/0x110
    netlink_unicast+0x17c/0x230
    netlink_sendmsg+0x2cd/0x3c0
    sock_sendmsg+0x30/0x40
    ___sys_sendmsg+0x27a/0x290
    __sys_sendmsg+0x51/0x90
    do_syscall_64+0x6e/0x1a0
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x7febca6deba0
    RSP: 002b:00007ffe7b0dd128 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007ffe7b0dd250 RCX: 00007febca6deba0
    RDX: 0000000000000000 RSI: 00007ffe7b0dd1a0 RDI: 0000000000000003
    RBP: 000000005aaa90cb R08: 0000000000000002 R09: 0000000000000000
    R10: 00007ffe7b0dcba0 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffe7b0dd264 R14: 0000000000000001 R15: 0000000000669f60
    Code: 44 00 00 8b 0d b5 23 00 00 48 8b 87 48 10 00 00 48 8b 3c c8 e9 a5 e5 d8 c3 0f 1f 44 00 00 0f 1f 44 00 00 53 48 8b 9f b0 00 00 00 7b 10 01 74 0b 48 89 df 31 f6 5b e9 f2 fa 7f c3 48 8b 7b 18
    RIP: tunnel_key_release+0xd/0x40 [act_tunnel_key] RSP: ffffba46803b7768
    CR2: 0000000000000010

    Fix this in tunnel_key_release(), ensuring 'param' is not NULL before
    dereferencing it.

    Fixes: d0f6dd8a914f ("net/sched: Introduce act_tunnel_key")
    Signed-off-by: Davide Caratti
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Davide Caratti
     
  • [ Upstream commit a117f73dc2430443f23e18367fa545981129c1a6 ]

    When mlx5_core is loaded it is expected to sync ports
    with all vxlan devices so it can support vxlan encap/decap.
    This is done via udp_tunnel_get_rx_info(). Currently this
    call is set in mlx5e_nic_enable() and if the netdev is not in
    NETREG_REGISTERED state it will not be called.

    Normally on load the netdev state is not NETREG_REGISTERED
    so udp_tunnel_get_rx_info() will not be called.

    Moving udp_tunnel_get_rx_info() to mlx5e_open() so
    it will be called on netdev UP event and allow encap/decap.

    Fixes: 610e89e05c3f ("net/mlx5e: Don't sync netdev state when not registered")
    Signed-off-by: Shahar Klein
    Reviewed-by: Roi Dayan
    Signed-off-by: Saeed Mahameed
    Signed-off-by: Greg Kroah-Hartman

    Shahar Klein
     
  • The vport admin original link state will be re-applied after returning
    back to legacy mode, it is not right to change the admin link state value
    when in switchdev mode.

    Use direct vport commands to alter logical vport state in netdev
    representor open/close flows rather than the administrative eswitch API.

    Fixes: 20a1ea674783 ('net/mlx5e: Support VF vport link state control for SRIOV switchdev mode')
    Signed-off-by: Jianbo Liu
    Reviewed-by: Roi Dayan
    Reviewed-by: Or Gerlitz
    Signed-off-by: Saeed Mahameed
    Signed-off-by: Greg Kroah-Hartman

    Jianbo Liu
     
  • [ Upstream commit 5807b22c9164a21cd1077a9bc587f0bba361f72d ]

    Enabling TSO can lead to abysmal performances when using seg6 in
    encap mode, such as with the ixgbe driver. This patch adds a call to
    iptunnel_handle_offloads() to remove the encapsulation bit if needed.

    Before:
    root@comp4-seg6bpf:~# iperf3 -c fc00::55
    Connecting to host fc00::55, port 5201
    [ 4] local fc45::4 port 36592 connected to fc00::55 port 5201
    [ ID] Interval Transfer Bandwidth Retr Cwnd
    [ 4] 0.00-1.00 sec 196 KBytes 1.60 Mbits/sec 47 6.66 KBytes
    [ 4] 1.00-2.00 sec 304 KBytes 2.49 Mbits/sec 100 5.33 KBytes
    [ 4] 2.00-3.00 sec 284 KBytes 2.32 Mbits/sec 92 5.33 KBytes

    After:
    root@comp4-seg6bpf:~# iperf3 -c fc00::55
    Connecting to host fc00::55, port 5201
    [ 4] local fc45::4 port 43062 connected to fc00::55 port 5201
    [ ID] Interval Transfer Bandwidth Retr Cwnd
    [ 4] 0.00-1.00 sec 1.03 GBytes 8.89 Gbits/sec 0 743 KBytes
    [ 4] 1.00-2.00 sec 1.03 GBytes 8.87 Gbits/sec 0 743 KBytes
    [ 4] 2.00-3.00 sec 1.03 GBytes 8.87 Gbits/sec 0 743 KBytes

    Reported-by: Tom Herbert
    Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: David Lebrun
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Lebrun
     
  • [ Upstream commit 1489bbd10e16079ce30a53d3c22a431fd47af791 ]

    The NSP default buffer is a piece of NFP memory where additional
    command data can be placed. Its format has been copied from
    host buffer, but the PCIe selection bits do not make sense in
    this case. If those get masked out from a NFP address - writes
    to random place in the chip memory may be issued and crash the
    device.

    Even in the general NSP buffer case, it doesn't make sense to have the
    PCIe selection bits there anymore. These are unused at the moment, and
    when it becomes necessary, the PCIe selection bits should rather be
    moved to another register to utilise more bits for the buffer address.

    This has never been an issue because the buffer used to be
    allocated in memory with less-than-38-bit-long address but that
    is about to change.

    Fixes: 1a64821c6af7 ("nfp: add support for service processor access")
    Signed-off-by: Dirk van der Merwe
    Reviewed-by: Jakub Kicinski
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Dirk van der Merwe
     
  • [ Upstream commit af1607c37d9d85a66fbcf43b7f11bf3d94b9bb69 ]

    For NIC flows, the parsed attributes are not freed when we exit
    successfully from mlx5e_configure_flower().

    There is possible double free for eswitch flows. If error is returned
    from rhashtable_insert_fast(), the parse attrs will be freed in
    mlx5e_tc_del_flow(), but they will be freed again before exiting
    mlx5e_configure_flower().

    To fix both issues we do the following:
    (1) change the condition that determines if to issue the free call to
    check if this flow is NIC flow, or it does not have encap action.
    (2) reorder the code such that that the check and free calls are done
    before we attempt to add into the hash table.

    Fixes: 232c001398ae ('net/mlx5e: Add support to neighbour update flow')
    Signed-off-by: Jianbo Liu
    Reviewed-by: Or Gerlitz
    Reviewed-by: Roi Dayan
    Signed-off-by: Saeed Mahameed
    Signed-off-by: Greg Kroah-Hartman

    Jianbo Liu
     
  • [ Upstream commit 423c9db29943cfc43e3a408192e9efa4178af6a1 ]

    Currently we use the global ipv6_stub var to access the ipv6 global
    nd table. This practice gets us to troubles when the stub is only partially
    set e.g when ipv6 is loaded under the disabled policy. In this case, as of commit
    343d60aada5a ("ipv6: change ipv6_stub_impl.ipv6_dst_lookup to take net argument")
    the stub is not null, but stub->nd_tbl is and we crash.

    As we can access the ipv6 nd_tbl directly, the fix is just to avoid the
    reference through the stub. There is one place in the code where we
    issue ipv6 route lookup and keep doing it through the stub, but that
    mentioned commit makes sure we get -EAFNOSUPPORT from the stack.

    Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
    Signed-off-by: Or Gerlitz
    Reviewed-by: Aviv Heller
    Signed-off-by: Saeed Mahameed
    Signed-off-by: Greg Kroah-Hartman

    Or Gerlitz