1. 31 Jan, 2019 4 commits
    • Alexei Starovoitov's avatar
      bpf: fix potential deadlock in bpf_prog_register · e16ec340
      Alexei Starovoitov authored
      Lockdep found a potential deadlock between cpu_hotplug_lock, bpf_event_mutex, and cpuctx_mutex:
      [   13.007000] WARNING: possible circular locking dependency detected
      [   13.007587] 5.0.0-rc3-00018-g2fa53f89-dirty #477 Not tainted
      [   13.008124] ------------------------------------------------------
      [   13.008624] test_progs/246 is trying to acquire lock:
      [   13.009030] 0000000094160d1d (tracepoints_mutex){+.+.}, at: tracepoint_probe_register_prio+0x2d/0x300
      [   13.009770]
      [   13.009770] but task is already holding lock:
      [   13.010239] 00000000d663ef86 (bpf_event_mutex){+.+.}, at: bpf_probe_register+0x1d/0x60
      [   13.010877]
      [   13.010877] which lock already depends on the new lock.
      [   13.010877]
      [   13.011532]
      [   13.011532] the existing dependency chain (in reverse order) is:
      [   13.012129]
      [   13.012129] -> #4 (bpf_event_mutex){+.+.}:
      [   13.012582]        perf_event_query_prog_array+0x9b/0x130
      [   13.013016]        _perf_ioctl+0x3aa/0x830
      [   13.013354]        perf_ioctl+0x2e/0x50
      [   13.013668]        do_vfs_ioctl+0x8f/0x6a0
      [   13.014003]        ksys_ioctl+0x70/0x80
      [   13.014320]        __x64_sys_ioctl+0x16/0x20
      [   13.014668]        do_syscall_64+0x4a/0x180
      [   13.015007]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   13.015469]
      [   13.015469] -> #3 (&cpuctx_mutex){+.+.}:
      [   13.015910]        perf_event_init_cpu+0x5a/0x90
      [   13.016291]        perf_event_init+0x1b2/0x1de
      [   13.016654]        start_kernel+0x2b8/0x42a
      [   13.016995]        secondary_startup_64+0xa4/0xb0
      [   13.017382]
      [   13.017382] -> #2 (pmus_lock){+.+.}:
      [   13.017794]        perf_event_init_cpu+0x21/0x90
      [   13.018172]        cpuhp_invoke_callback+0xb3/0x960
      [   13.018573]        _cpu_up+0xa7/0x140
      [   13.018871]        do_cpu_up+0xa4/0xc0
      [   13.019178]        smp_init+0xcd/0xd2
      [   13.019483]        kernel_init_freeable+0x123/0x24f
      [   13.019878]        kernel_init+0xa/0x110
      [   13.020201]        ret_from_fork+0x24/0x30
      [   13.020541]
      [   13.020541] -> #1 (cpu_hotplug_lock.rw_sem){++++}:
      [   13.021051]        static_key_slow_inc+0xe/0x20
      [   13.021424]        tracepoint_probe_register_prio+0x28c/0x300
      [   13.021891]        perf_trace_event_init+0x11f/0x250
      [   13.022297]        perf_trace_init+0x6b/0xa0
      [   13.022644]        perf_tp_event_init+0x25/0x40
      [   13.023011]        perf_try_init_event+0x6b/0x90
      [   13.023386]        perf_event_alloc+0x9a8/0xc40
      [   13.023754]        __do_sys_perf_event_open+0x1dd/0xd30
      [   13.024173]        do_syscall_64+0x4a/0x180
      [   13.024519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   13.024968]
      [   13.024968] -> #0 (tracepoints_mutex){+.+.}:
      [   13.025434]        __mutex_lock+0x86/0x970
      [   13.025764]        tracepoint_probe_register_prio+0x2d/0x300
      [   13.026215]        bpf_probe_register+0x40/0x60
      [   13.026584]        bpf_raw_tracepoint_open.isra.34+0xa4/0x130
      [   13.027042]        __do_sys_bpf+0x94f/0x1a90
      [   13.027389]        do_syscall_64+0x4a/0x180
      [   13.027727]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   13.028171]
      [   13.028171] other info that might help us debug this:
      [   13.028171]
      [   13.028807] Chain exists of:
      [   13.028807]   tracepoints_mutex --> &cpuctx_mutex --> bpf_event_mutex
      [   13.028807]
      [   13.029666]  Possible unsafe locking scenario:
      [   13.029666]
      [   13.030140]        CPU0                    CPU1
      [   13.030510]        ----                    ----
      [   13.030875]   lock(bpf_event_mutex);
      [   13.031166]                                lock(&cpuctx_mutex);
      [   13.031645]                                lock(bpf_event_mutex);
      [   13.032135]   lock(tracepoints_mutex);
      [   13.032441]
      [   13.032441]  *** DEADLOCK ***
      [   13.032441]
      [   13.032911] 1 lock held by test_progs/246:
      [   13.033239]  #0: 00000000d663ef86 (bpf_event_mutex){+.+.}, at: bpf_probe_register+0x1d/0x60
      [   13.033909]
      [   13.033909] stack backtrace:
      [   13.034258] CPU: 1 PID: 246 Comm: test_progs Not tainted 5.0.0-rc3-00018-g2fa53f89-dirty #477
      [   13.034964] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
      [   13.035657] Call Trace:
      [   13.035859]  dump_stack+0x5f/0x8b
      [   13.036130]  print_circular_bug.isra.37+0x1ce/0x1db
      [   13.036526]  __lock_acquire+0x1158/0x1350
      [   13.036852]  ? lock_acquire+0x98/0x190
      [   13.037154]  lock_acquire+0x98/0x190
      [   13.037447]  ? tracepoint_probe_register_prio+0x2d/0x300
      [   13.037876]  __mutex_lock+0x86/0x970
      [   13.038167]  ? tracepoint_probe_register_prio+0x2d/0x300
      [   13.038600]  ? tracepoint_probe_register_prio+0x2d/0x300
      [   13.039028]  ? __mutex_lock+0x86/0x970
      [   13.039337]  ? __mutex_lock+0x24a/0x970
      [   13.039649]  ? bpf_probe_register+0x1d/0x60
      [   13.039992]  ? __bpf_trace_sched_wake_idle_without_ipi+0x10/0x10
      [   13.040478]  ? tracepoint_probe_register_prio+0x2d/0x300
      [   13.040906]  tracepoint_probe_register_prio+0x2d/0x300
      [   13.041325]  bpf_probe_register+0x40/0x60
      [   13.041649]  bpf_raw_tracepoint_open.isra.34+0xa4/0x130
      [   13.042068]  ? __might_fault+0x3e/0x90
      [   13.042374]  __do_sys_bpf+0x94f/0x1a90
      [   13.042678]  do_syscall_64+0x4a/0x180
      [   13.042975]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   13.043382] RIP: 0033:0x7f23b10a07f9
      [   13.045155] RSP: 002b:00007ffdef42fdd8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141
      [   13.045759] RAX: ffffffffffffffda RBX: 00007ffdef42ff70 RCX: 00007f23b10a07f9
      [   13.046326] RDX: 0000000000000070 RSI: 00007ffdef42fe10 RDI: 0000000000000011
      [   13.046893] RBP: 00007ffdef42fdf0 R08: 0000000000000038 R09: 00007ffdef42fe10
      [   13.047462] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
      [   13.048029] R13: 0000000000000016 R14: 00007f23b1db4690 R15: 0000000000000000
      
      Since tracepoints_mutex will be taken in tracepoint_probe_register/unregister()
      there is no need to take bpf_event_mutex too.
      bpf_event_mutex is protecting modifications to prog array used in kprobe/perf bpf progs.
      bpf_raw_tracepoints don't need to take this mutex.
      
      Fixes: c4f6699d ("bpf: introduce BPF_RAW_TRACEPOINT")
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      e16ec340
    • Alexei Starovoitov's avatar
      bpf: fix lockdep false positive in percpu_freelist · a89fac57
      Alexei Starovoitov authored
      Lockdep warns about false positive:
      [   12.492084] 00000000e6b28347 (&head->lock){+...}, at: pcpu_freelist_push+0x2a/0x40
      [   12.492696] but this lock was taken by another, HARDIRQ-safe lock in the past:
      [   12.493275]  (&rq->lock){-.-.}
      [   12.493276]
      [   12.493276]
      [   12.493276] and interrupts could create inverse lock ordering between them.
      [   12.493276]
      [   12.494435]
      [   12.494435] other info that might help us debug this:
      [   12.494979]  Possible interrupt unsafe locking scenario:
      [   12.494979]
      [   12.495518]        CPU0                    CPU1
      [   12.495879]        ----                    ----
      [   12.496243]   lock(&head->lock);
      [   12.496502]                                local_irq_disable();
      [   12.496969]                                lock(&rq->lock);
      [   12.497431]                                lock(&head->lock);
      [   12.497890]   <Interrupt>
      [   12.498104]     lock(&rq->lock);
      [   12.498368]
      [   12.498368]  *** DEADLOCK ***
      [   12.498368]
      [   12.498837] 1 lock held by dd/276:
      [   12.499110]  #0: 00000000c58cb2ee (rcu_read_lock){....}, at: trace_call_bpf+0x5e/0x240
      [   12.499747]
      [   12.499747] the shortest dependencies between 2nd lock and 1st lock:
      [   12.500389]  -> (&rq->lock){-.-.} {
      [   12.500669]     IN-HARDIRQ-W at:
      [   12.500934]                       _raw_spin_lock+0x2f/0x40
      [   12.501373]                       scheduler_tick+0x4c/0xf0
      [   12.501812]                       update_process_times+0x40/0x50
      [   12.502294]                       tick_periodic+0x27/0xb0
      [   12.502723]                       tick_handle_periodic+0x1f/0x60
      [   12.503203]                       timer_interrupt+0x11/0x20
      [   12.503651]                       __handle_irq_event_percpu+0x43/0x2c0
      [   12.504167]                       handle_irq_event_percpu+0x20/0x50
      [   12.504674]                       handle_irq_event+0x37/0x60
      [   12.505139]                       handle_level_irq+0xa7/0x120
      [   12.505601]                       handle_irq+0xa1/0x150
      [   12.506018]                       do_IRQ+0x77/0x140
      [   12.506411]                       ret_from_intr+0x0/0x1d
      [   12.506834]                       _raw_spin_unlock_irqrestore+0x53/0x60
      [   12.507362]                       __setup_irq+0x481/0x730
      [   12.507789]                       setup_irq+0x49/0x80
      [   12.508195]                       hpet_time_init+0x21/0x32
      [   12.508644]                       x86_late_time_init+0xb/0x16
      [   12.509106]                       start_kernel+0x390/0x42a
      [   12.509554]                       secondary_startup_64+0xa4/0xb0
      [   12.510034]     IN-SOFTIRQ-W at:
      [   12.510305]                       _raw_spin_lock+0x2f/0x40
      [   12.510772]                       try_to_wake_up+0x1c7/0x4e0
      [   12.511220]                       swake_up_locked+0x20/0x40
      [   12.511657]                       swake_up_one+0x1a/0x30
      [   12.512070]                       rcu_process_callbacks+0xc5/0x650
      [   12.512553]                       __do_softirq+0xe6/0x47b
      [   12.512978]                       irq_exit+0xc3/0xd0
      [   12.513372]                       smp_apic_timer_interrupt+0xa9/0x250
      [   12.513876]                       apic_timer_interrupt+0xf/0x20
      [   12.514343]                       default_idle+0x1c/0x170
      [   12.514765]                       do_idle+0x199/0x240
      [   12.515159]                       cpu_startup_entry+0x19/0x20
      [   12.515614]                       start_kernel+0x422/0x42a
      [   12.516045]                       secondary_startup_64+0xa4/0xb0
      [   12.516521]     INITIAL USE at:
      [   12.516774]                      _raw_spin_lock_irqsave+0x38/0x50
      [   12.517258]                      rq_attach_root+0x16/0xd0
      [   12.517685]                      sched_init+0x2f2/0x3eb
      [   12.518096]                      start_kernel+0x1fb/0x42a
      [   12.518525]                      secondary_startup_64+0xa4/0xb0
      [   12.518986]   }
      [   12.519132]   ... key      at: [<ffffffff82b7bc28>] __key.71384+0x0/0x8
      [   12.519649]   ... acquired at:
      [   12.519892]    pcpu_freelist_pop+0x7b/0xd0
      [   12.520221]    bpf_get_stackid+0x1d2/0x4d0
      [   12.520563]    ___bpf_prog_run+0x8b4/0x11a0
      [   12.520887]
      [   12.521008] -> (&head->lock){+...} {
      [   12.521292]    HARDIRQ-ON-W at:
      [   12.521539]                     _raw_spin_lock+0x2f/0x40
      [   12.521950]                     pcpu_freelist_push+0x2a/0x40
      [   12.522396]                     bpf_get_stackid+0x494/0x4d0
      [   12.522828]                     ___bpf_prog_run+0x8b4/0x11a0
      [   12.523296]    INITIAL USE at:
      [   12.523537]                    _raw_spin_lock+0x2f/0x40
      [   12.523944]                    pcpu_freelist_populate+0xc0/0x120
      [   12.524417]                    htab_map_alloc+0x405/0x500
      [   12.524835]                    __do_sys_bpf+0x1a3/0x1a90
      [   12.525253]                    do_syscall_64+0x4a/0x180
      [   12.525659]                    entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   12.526167]  }
      [   12.526311]  ... key      at: [<ffffffff838f7668>] __key.13130+0x0/0x8
      [   12.526812]  ... acquired at:
      [   12.527047]    __lock_acquire+0x521/0x1350
      [   12.527371]    lock_acquire+0x98/0x190
      [   12.527680]    _raw_spin_lock+0x2f/0x40
      [   12.527994]    pcpu_freelist_push+0x2a/0x40
      [   12.528325]    bpf_get_stackid+0x494/0x4d0
      [   12.528645]    ___bpf_prog_run+0x8b4/0x11a0
      [   12.528970]
      [   12.529092]
      [   12.529092] stack backtrace:
      [   12.529444] CPU: 0 PID: 276 Comm: dd Not tainted 5.0.0-rc3-00018-g2fa53f89 #475
      [   12.530043] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
      [   12.530750] Call Trace:
      [   12.530948]  dump_stack+0x5f/0x8b
      [   12.531248]  check_usage_backwards+0x10c/0x120
      [   12.531598]  ? ___bpf_prog_run+0x8b4/0x11a0
      [   12.531935]  ? mark_lock+0x382/0x560
      [   12.532229]  mark_lock+0x382/0x560
      [   12.532496]  ? print_shortest_lock_dependencies+0x180/0x180
      [   12.532928]  __lock_acquire+0x521/0x1350
      [   12.533271]  ? find_get_entry+0x17f/0x2e0
      [   12.533586]  ? find_get_entry+0x19c/0x2e0
      [   12.533902]  ? lock_acquire+0x98/0x190
      [   12.534196]  lock_acquire+0x98/0x190
      [   12.534482]  ? pcpu_freelist_push+0x2a/0x40
      [   12.534810]  _raw_spin_lock+0x2f/0x40
      [   12.535099]  ? pcpu_freelist_push+0x2a/0x40
      [   12.535432]  pcpu_freelist_push+0x2a/0x40
      [   12.535750]  bpf_get_stackid+0x494/0x4d0
      [   12.536062]  ___bpf_prog_run+0x8b4/0x11a0
      
      It has been explained that is a false positive here:
      https://lkml.org/lkml/2018/7/25/756
      Recap:
      - stackmap uses pcpu_freelist
      - The lock in pcpu_freelist is a percpu lock
      - stackmap is only used by tracing bpf_prog
      - A tracing bpf_prog cannot be run if another bpf_prog
        has already been running (ensured by the percpu bpf_prog_active counter).
      
      Eric pointed out that this lockdep splats stops other
      legit lockdep splats in selftests/bpf/test_progs.c.
      
      Fix this by calling local_irq_save/restore for stackmap.
      
      Another false positive had also been worked around by calling
      local_irq_save in commit 89ad2fa3 ("bpf: fix lockdep splat").
      That commit added unnecessary irq_save/restore to fast path of
      bpf hash map. irqs are already disabled at that point, since htab
      is holding per bucket spin_lock with irqsave.
      
      Let's reduce overhead for htab by introducing __pcpu_freelist_push/pop
      function w/o irqsave and convert pcpu_freelist_push/pop to irqsave
      to be used elsewhere (right now only in stackmap).
      It stops lockdep false positive in stackmap with a bit of acceptable overhead.
      
      Fixes: 557c0c6e ("bpf: convert stackmap to pre-allocation")
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      a89fac57
    • Alexei Starovoitov's avatar
      bpf: run bpf programs with preemption disabled · 6cab5e90
      Alexei Starovoitov authored
      Disabled preemption is necessary for proper access to per-cpu maps
      from BPF programs.
      
      But the sender side of socket filters didn't have preemption disabled:
      unix_dgram_sendmsg->sk_filter->sk_filter_trim_cap->bpf_prog_run_save_cb->BPF_PROG_RUN
      
      and a combination of af_packet with tun device didn't disable either:
      tpacket_snd->packet_direct_xmit->packet_pick_tx_queue->ndo_select_queue->
        tun_select_queue->tun_ebpf_select_queue->bpf_prog_run_clear_cb->BPF_PROG_RUN
      
      Disable preemption before executing BPF programs (both classic and extended).
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      6cab5e90
    • Martynas Pumputis's avatar
      bpf, selftests: fix handling of sparse CPU allocations · 1bb54c40
      Martynas Pumputis authored
      Previously, bpf_num_possible_cpus() had a bug when calculating a
      number of possible CPUs in the case of sparse CPU allocations, as
      it was considering only the first range or element of
      /sys/devices/system/cpu/possible.
      
      E.g. in the case of "0,2-3" (CPU 1 is not available), the function
      returned 1 instead of 3.
      
      This patch fixes the function by making it parse all CPU ranges and
      elements.
      Signed-off-by: default avatarMartynas Pumputis <m@lambda.lt>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      1bb54c40
  2. 30 Jan, 2019 3 commits
  3. 29 Jan, 2019 1 commit
  4. 28 Jan, 2019 2 commits
    • Jakub Sitnicki's avatar
      sk_msg: Always cancel strp work before freeing the psock · 1d79895a
      Jakub Sitnicki authored
      Despite having stopped the parser, we still need to deinitialize it
      by calling strp_done so that it cancels its work. Otherwise the worker
      thread can run after we have freed the parser, and attempt to access
      its workqueue resulting in a use-after-free:
      
      ==================================================================
      BUG: KASAN: use-after-free in pwq_activate_delayed_work+0x1b/0x1d0
      Read of size 8 at addr ffff888069975240 by task kworker/u2:2/93
      
      CPU: 0 PID: 93 Comm: kworker/u2:2 Not tainted 5.0.0-rc2-00335-g28f9d1a3-dirty #14
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
      Workqueue:            (null) (kstrp)
      Call Trace:
       print_address_description+0x6e/0x2b0
       ? pwq_activate_delayed_work+0x1b/0x1d0
       kasan_report+0xfd/0x177
       ? pwq_activate_delayed_work+0x1b/0x1d0
       ? pwq_activate_delayed_work+0x1b/0x1d0
       pwq_activate_delayed_work+0x1b/0x1d0
       ? process_one_work+0x4aa/0x660
       pwq_dec_nr_in_flight+0x9b/0x100
       worker_thread+0x82/0x680
       ? process_one_work+0x660/0x660
       kthread+0x1b9/0x1e0
       ? __kthread_create_on_node+0x250/0x250
       ret_from_fork+0x1f/0x30
      
      Allocated by task 111:
       sk_psock_init+0x3c/0x1b0
       sock_map_link.isra.2+0x103/0x4b0
       sock_map_update_common+0x94/0x270
       sock_map_update_elem+0x145/0x160
       __se_sys_bpf+0x152e/0x1e10
       do_syscall_64+0xb2/0x3e0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 112:
       kfree+0x7f/0x140
       process_one_work+0x40b/0x660
       worker_thread+0x82/0x680
       kthread+0x1b9/0x1e0
       ret_from_fork+0x1f/0x30
      
      The buggy address belongs to the object at ffff888069975180
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 192 bytes inside of
       512-byte region [ffff888069975180, ffff888069975380)
      The buggy address belongs to the page:
      page:ffffea0001a65d00 count:1 mapcount:0 mapping:ffff88806d401280 index:0x0 compound_mapcount: 0
      flags: 0x4000000000010200(slab|head)
      raw: 4000000000010200 dead000000000100 dead000000000200 ffff88806d401280
      raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888069975100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888069975180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff888069975200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                 ^
       ffff888069975280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888069975300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      Reported-by: default avatarMarek Majkowski <marek@cloudflare.com>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Link: https://lore.kernel.org/netdev/CAJPywTLwgXNEZ2dZVoa=udiZmtrWJ0q5SuBW64aYs0Y1khXX3A@mail.gmail.comAcked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      1d79895a
    • Jakub Kicinski's avatar
      tools: bpftool: fix crash with un-owned prog arrays · 8c79b356
      Jakub Kicinski authored
      Prog arrays don't have 'owner_prog_type' and 'owner_jited'
      fields in their fdinfo when they are created.  Those fields
      are set and reported when first program is checked for
      compatibility by bpf_prog_array_compatible().
      
      This means that bpftool cannot expect the fields to always
      be there.  Currently trying to show maps on a system with
      an un-owned prog array leads to a crash:
      
      $ bpftool map show
      389: prog_array  name tail_call_map  flags 0x0
      Error: key 'owner_prog_type' not found in fdinfo
      Error: key 'owner_jited' not found in fdinfo
             key 4B  value 4B  max_entries 4  memlock 4096B
             Segmentation fault (core dumped)
      
      We pass a NULL pointer to atoi().
      
      Remove the assumption that fdinfo keys are always present.
      Add missing validations and remove the p_err() calls which
      may lead to broken JSON output as caller will not propagate
      the failure.
      
      Fixes: 99a44bef ("tools: bpftool: add owner_prog_type and owner_jited to bpftool output")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      8c79b356
  5. 23 Jan, 2019 13 commits
  6. 22 Jan, 2019 2 commits
    • Lorenzo Bianconi's avatar
      net: ip_gre: use erspan key field for tunnel lookup · cb73ee40
      Lorenzo Bianconi authored
      Use ERSPAN key header field as tunnel key in gre_parse_header routine
      since ERSPAN protocol sets the key field of the external GRE header to
      0 resulting in a tunnel lookup fail in ip6gre_err.
      In addition remove key field parsing and pskb_may_pull check in
      erspan_rcv and ip6erspan_rcv
      
      Fixes: 5a963eb6 ("ip6_gre: Add ERSPAN native tunnel support")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb73ee40
    • Thomas Gleixner's avatar
      net: sun: cassini: Cleanup license conflict · 56cb4e50
      Thomas Gleixner authored
      The recent addition of SPDX license identifiers to the files in
      drivers/net/ethernet/sun created a licensing conflict.
      
      The cassini driver files contain a proper license notice:
      
        * This program is free software; you can redistribute it and/or
        * modify it under the terms of the GNU General Public License as
        * published by the Free Software Foundation; either version 2 of the
        * License, or (at your option) any later version.
      
      but the SPDX change added:
      
         SPDX-License-Identifier: GPL-2.0
      
      So the file got tagged GPL v2 only while in fact it is licensed under GPL
      v2 or later.
      
      It's nice that people care about the SPDX tags, but they need to be more
      careful about it. Not everything under (the) sun belongs to ...
      
      Fix up the SPDX identifier and remove the boiler plate text as it is
      redundant.
      
      Fixes: c861ef83 ("sun: Add SPDX license tags to Sun network drivers")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Shannon Nelson <shannon.nelson@oracle.com>
      Cc: Zhu Yanjun <yanjun.zhu@oracle.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: stable@vger.kernel.org
      Acked-by: default avatarShannon Nelson <shannon.lee.nelson@gmail.com>
      Reviewed-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56cb4e50
  7. 21 Jan, 2019 3 commits
  8. 20 Jan, 2019 12 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 7d0ae236
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix endless loop in nf_tables, from Phil Sutter.
      
       2) Fix cross namespace ip6_gre tunnel hash list corruption, from
          Olivier Matz.
      
       3) Don't be too strict in phy_start_aneg() otherwise we might not allow
          restarting auto negotiation. From Heiner Kallweit.
      
       4) Fix various KMSAN uninitialized value cases in tipc, from Ying Xue.
      
       5) Memory leak in act_tunnel_key, from Davide Caratti.
      
       6) Handle chip errata of mv88e6390 PHY, from Andrew Lunn.
      
       7) Remove linear SKB assumption in fou/fou6, from Eric Dumazet.
      
       8) Missing udplite rehash callbacks, from Alexey Kodanev.
      
       9) Log dirty pages properly in vhost, from Jason Wang.
      
      10) Use consume_skb() in neigh_probe() as this is a normal free not a
          drop, from Yang Wei. Likewise in macvlan_process_broadcast().
      
      11) Missing device_del() in mdiobus_register() error paths, from Thomas
          Petazzoni.
      
      12) Fix checksum handling of short packets in mlx5, from Cong Wang.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (96 commits)
        bpf: in __bpf_redirect_no_mac pull mac only if present
        virtio_net: bulk free tx skbs
        net: phy: phy driver features are mandatory
        isdn: avm: Fix string plus integer warning from Clang
        net/mlx5e: Fix cb_ident duplicate in indirect block register
        net/mlx5e: Fix wrong (zero) TX drop counter indication for representor
        net/mlx5e: Fix wrong error code return on FEC query failure
        net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames
        tools: bpftool: Cleanup license mess
        bpf: fix inner map masking to prevent oob under speculation
        bpf: pull in pkt_sched.h header for tooling to fix bpftool build
        selftests: forwarding: Add a test case for externally learned FDB entries
        selftests: mlxsw: Test FDB offload indication
        mlxsw: spectrum_switchdev: Do not treat static FDB entries as sticky
        net: bridge: Mark FDB entries that were added by user as such
        mlxsw: spectrum_fid: Update dummy FID index
        mlxsw: pci: Return error on PCI reset timeout
        mlxsw: pci: Increase PCI SW reset timeout
        mlxsw: pci: Ring CQ's doorbell before RDQ's
        MAINTAINERS: update email addresses of liquidio driver maintainers
        ...
      7d0ae236
    • Kees Cook's avatar
      pstore/ram: Avoid allocation and leak of platform data · 5631e857
      Kees Cook authored
      Yue Hu noticed that when parsing device tree the allocated platform data
      was never freed. Since it's not used beyond the function scope, this
      switches to using a stack variable instead.
      Reported-by: default avatarYue Hu <huyue2@yulong.com>
      Fixes: 35da6094 ("pstore/ram: add Device Tree bindings")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      5631e857
    • Ard Biesheuvel's avatar
      gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+ · 2c88c742
      Ard Biesheuvel authored
      GCC 9 reworks the way the references to the stack canary are
      emitted, to prevent the value from being spilled to the stack
      before the final comparison in the epilogue, defeating the
      purpose, given that the spill slot is under control of the
      attacker that we are protecting ourselves from.
      
      Since our canary value address is obtained without accessing
      memory (as opposed to pre-v7 code that will obtain it from a
      literal pool), it is unlikely (although not guaranteed) that
      the compiler will spill the canary value in the same way, so
      let's just disable this improvement when building with GCC9+.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      2c88c742
    • Ard Biesheuvel's avatar
      gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP mask · 560706d5
      Ard Biesheuvel authored
      The ARM per-task stack protector GCC plugin hits an assert in
      the compiler in some case, due to the fact the the SP mask
      expression is not sign-extended as it should be. So fix that.
      Suggested-by: default avatarKugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      560706d5
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · bb617b9b
      Linus Torvalds authored
      Pull virtio/vhost fixes and cleanups from Michael Tsirkin:
       "Fixes and cleanups all over the place"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        vhost/scsi: Use copy_to_iter() to send control queue response
        vhost: return EINVAL if iovecs size does not match the message size
        virtio-balloon: tweak config_changed implementation
        virtio: don't allocate vqs when names[i] = NULL
        virtio_pci: use queue idx instead of array idx to set up the vq
        virtio: document virtio_config_ops restrictions
        virtio: fix virtio_config_ops description
      bb617b9b
    • Linus Torvalds's avatar
      Merge tag 'for-5.0-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 1be969f4
      Linus Torvalds authored
      Pull btrfs fixes from David Sterba:
       "A handful of fixes (some of them in testing for a long time):
      
         - fix some test failures regarding cleanup after transaction abort
      
         - revert of a patch that could cause a deadlock
      
         - delayed iput fixes, that can help in ENOSPC situation when there's
           low space and a lot data to write"
      
      * tag 'for-5.0-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: wakeup cleaner thread when adding delayed iput
        btrfs: run delayed iputs before committing
        btrfs: wait on ordered extents on abort cleanup
        btrfs: handle delayed ref head accounting cleanup in abort
        Revert "btrfs: balance dirty metadata pages in btrfs_finish_ordered_io"
      1be969f4
    • Linus Torvalds's avatar
      Merge tags 'compiler-attributes-for-linus-v5.0-rc3' and... · 315a6d85
      Linus Torvalds authored
      Merge tags 'compiler-attributes-for-linus-v5.0-rc3' and 'clang-format-for-linus-v5.0-rc3' of git://github.com/ojeda/linux
      
      Pull misc clang fixes from Miguel Ojeda:
      
        - A fix for OPTIMIZER_HIDE_VAR from Michael S Tsirkin
      
        - Update clang-format with the latest for_each macro list from Jason
          Gunthorpe
      
      * tag 'compiler-attributes-for-linus-v5.0-rc3' of git://github.com/ojeda/linux:
        include/linux/compiler*.h: fix OPTIMIZER_HIDE_VAR
      
      * tag 'clang-format-for-linus-v5.0-rc3' of git://github.com/ojeda/linux:
        clang-format: Update .clang-format with the latest for_each macro list
      315a6d85
    • Florian La Roche's avatar
      fix int_sqrt64() for very large numbers · fbfaf851
      Florian La Roche authored
      If an input number x for int_sqrt64() has the highest bit set, then
      fls64(x) is 64.  (1UL << 64) is an overflow and breaks the algorithm.
      
      Subtracting 1 is a better guess for the initial value of m anyway and
      that's what also done in int_sqrt() implicitly [*].
      
      [*] Note how int_sqrt() uses __fls() with two underscores, which already
          returns the proper raw bit number.
      
          In contrast, int_sqrt64() used fls64(), and that returns bit numbers
          illogically starting at 1, because of error handling for the "no
          bits set" case. Will points out that he bug probably is due to a
          copy-and-paste error from the regular int_sqrt() case.
      Signed-off-by: default avatarFlorian La Roche <Florian.LaRoche@googlemail.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fbfaf851
    • Will Deacon's avatar
      x86: uaccess: Inhibit speculation past access_ok() in user_access_begin() · 6e693b3f
      Will Deacon authored
      Commit 594cc251 ("make 'user_access_begin()' do 'access_ok()'")
      makes the access_ok() check part of the user_access_begin() preceding a
      series of 'unsafe' accesses.  This has the desirable effect of ensuring
      that all 'unsafe' accesses have been range-checked, without having to
      pick through all of the callsites to verify whether the appropriate
      checking has been made.
      
      However, the consolidated range check does not inhibit speculation, so
      it is still up to the caller to ensure that they are not susceptible to
      any speculative side-channel attacks for user addresses that ultimately
      fail the access_ok() check.
      
      This is an oversight, so use __uaccess_begin_nospec() to ensure that
      speculation is inhibited until the access_ok() check has passed.
      Reported-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6e693b3f
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · b0f3e768
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "Three arm64 fixes for -rc3.
      
        We've plugged a couple of nasty issues involving KASLR-enabled
        kernels, and removed a redundant #define that was introduced as part
        of the KHWASAN fixes from akpm at -rc2.
      
         - Fix broken kpti page-table rewrite in bizarre KASLR configuration
      
         - Fix module loading with KASLR
      
         - Remove redundant definition of ARCH_SLAB_MINALIGN"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define
        arm64: kaslr: ensure randomized quantities are clean to the PoC
        arm64: kpti: Update arm64_kernel_use_ng_mappings() when forced on
      b0f3e768
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 6436408e
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2019-01-20
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix a out-of-bounds access in __bpf_redirect_no_mac, from Willem.
      
      2) Fix bpf_setsockopt to reset sock dst on SO_MARK changes, from Peter.
      
      3) Fix map in map masking to prevent out-of-bounds access under
         speculative execution, from Daniel.
      
      4) Fix bpf_setsockopt's SO_MAX_PACING_RATE to support TCP internal
         pacing, from Yuchung.
      
      5) Fix json writer license in bpftool, from Thomas.
      
      6) Fix AF_XDP to check if an actually queue exists during umem
         setup, from Krzysztof.
      
      7) Several fixes to BPF stackmap's build id handling. Another fix
         for bpftool build to account for libbfd variations wrt linking
         requirements, from Stanislav.
      
      8) Fix BPF samples build with clang by working around missing asm
         goto, from Yonghong.
      
      9) Fix libbpf to retry program load on signal interrupt, from Lorenz.
      
      10) Various minor compile warning fixes in BPF code, from Mathieu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6436408e
    • Willem de Bruijn's avatar
      bpf: in __bpf_redirect_no_mac pull mac only if present · e7c87bd6
      Willem de Bruijn authored
      Syzkaller was able to construct a packet of negative length by
      redirecting from bpf_prog_test_run_skb with BPF_PROG_TYPE_LWT_XMIT:
      
          BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:345 [inline]
          BUG: KASAN: slab-out-of-bounds in skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline]
          BUG: KASAN: slab-out-of-bounds in __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395
          Read of size 4294967282 at addr ffff8801d798009c by task syz-executor2/12942
      
          kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
          check_memory_region_inline mm/kasan/kasan.c:260 [inline]
          check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
          memcpy+0x23/0x50 mm/kasan/kasan.c:302
          memcpy include/linux/string.h:345 [inline]
          skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline]
          __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395
          __pskb_copy include/linux/skbuff.h:1053 [inline]
          pskb_copy include/linux/skbuff.h:2904 [inline]
          skb_realloc_headroom+0xe7/0x120 net/core/skbuff.c:1539
          ipip6_tunnel_xmit net/ipv6/sit.c:965 [inline]
          sit_tunnel_xmit+0xe1b/0x30d0 net/ipv6/sit.c:1029
          __netdev_start_xmit include/linux/netdevice.h:4325 [inline]
          netdev_start_xmit include/linux/netdevice.h:4334 [inline]
          xmit_one net/core/dev.c:3219 [inline]
          dev_hard_start_xmit+0x295/0xc90 net/core/dev.c:3235
          __dev_queue_xmit+0x2f0d/0x3950 net/core/dev.c:3805
          dev_queue_xmit+0x17/0x20 net/core/dev.c:3838
          __bpf_tx_skb net/core/filter.c:2016 [inline]
          __bpf_redirect_common net/core/filter.c:2054 [inline]
          __bpf_redirect+0x5cf/0xb20 net/core/filter.c:2061
          ____bpf_clone_redirect net/core/filter.c:2094 [inline]
          bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2066
          bpf_prog_41f2bcae09cd4ac3+0xb25/0x1000
      
      The generated test constructs a packet with mac header, network
      header, skb->data pointing to network header and skb->len 0.
      
      Redirecting to a sit0 through __bpf_redirect_no_mac pulls the
      mac length, even though skb->data already is at skb->network_header.
      bpf_prog_test_run_skb has already pulled it as LWT_XMIT !is_l2.
      
      Update the offset calculation to pull only if skb->data differs
      from skb->network_header, which is not true in this case.
      
      The test itself can be run only from commit 1cf1cae9 ("bpf:
      introduce BPF_PROG_TEST_RUN command"), but the same type of packets
      with skb at network header could already be built from lwt xmit hooks,
      so this fix is more relevant to that commit.
      
      Also set the mac header on redirect from LWT_XMIT, as even after this
      change to __bpf_redirect_no_mac that field is expected to be set, but
      is not yet in ip_finish_output2.
      
      Fixes: 3a0af8fd ("bpf: BPF for lightweight tunnel infrastructure")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      e7c87bd6