1. 21 Apr, 2016 5 commits
  2. 20 Apr, 2016 24 commits
  3. 19 Apr, 2016 8 commits
    • Jakub Sitnicki's avatar
      ipv6: Count in extension headers in skb->network_header · 9dfcd3a8
      Jakub Sitnicki authored
      [ Upstream commit 3ba3458f ]
      
      When sending a UDPv6 message longer than MTU, account for the length
      of fragmentable IPv6 extension headers in skb->network_header offset.
      Same as we do in alloc_new_skb path in __ip6_append_data().
      
      This ensures that later on __ip6_make_skb() will make space in
      headroom for fragmentable extension headers:
      
      	/* move skb->data to ip header from ext header */
      	if (skb->data < skb_network_header(skb))
      		__skb_pull(skb, skb_network_offset(skb));
      
      Prevents a splat due to skb_under_panic:
      
      skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \
      head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:104!
      invalid opcode: 0000 [#1] KASAN
      CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65
      [...]
      Call Trace:
       [<ffffffff813eb7b9>] skb_push+0x79/0x80
       [<ffffffff8143397b>] eth_header+0x2b/0x100
       [<ffffffff8141e0d0>] neigh_resolve_output+0x210/0x310
       [<ffffffff814eab77>] ip6_finish_output2+0x4a7/0x7c0
       [<ffffffff814efe3a>] ip6_output+0x16a/0x280
       [<ffffffff815440c1>] ip6_local_out+0xb1/0xf0
       [<ffffffff814f1115>] ip6_send_skb+0x45/0xd0
       [<ffffffff81518836>] udp_v6_send_skb+0x246/0x5d0
       [<ffffffff8151985e>] udpv6_sendmsg+0xa6e/0x1090
      [...]
      Reported-by: default avatarJi Jianwen <jiji@redhat.com>
      Signed-off-by: default avatarJakub Sitnicki <jkbs@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9dfcd3a8
    • Thadeu Lima de Souza Cascardo's avatar
      ip6_tunnel: set rtnl_link_ops before calling register_netdevice · 4eb6e92e
      Thadeu Lima de Souza Cascardo authored
      [ Upstream commit b6ee376c ]
      
      When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
      before ip6_tnl_create2 is called. When register_netdevice is called, there
      is no linkinfo attribute in the NEWLINK message because of that.
      
      Setting rtnl_link_ops before calling register_netdevice fixes that.
      
      Fixes: 0b112457 ("ip6tnl: add support of link creation via rtnl")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4eb6e92e
    • Haishuang Yan's avatar
      ipv6: l2tp: fix a potential issue in l2tp_ip6_recv · 80136dc2
      Haishuang Yan authored
      [ Upstream commit be447f30 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      80136dc2
    • Haishuang Yan's avatar
      ipv4: l2tp: fix a potential issue in l2tp_ip_recv · 4a05fe25
      Haishuang Yan authored
      [ Upstream commit 5745b823 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4a05fe25
    • subashab@codeaurora.org's avatar
      xfrm: Fix crash observed during device unregistration and decryption · e1e03d36
      subashab@codeaurora.org authored
      [ Upstream commit 071d36bf ]
      
      A crash is observed when a decrypted packet is processed in receive
      path. get_rps_cpus() tries to dereference the skb->dev fields but it
      appears that the device is freed from the poison pattern.
      
      [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
      [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
      [<ffffffc000af6094>] netif_rx+0x74/0x94
      [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
      [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
      [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
      [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
      [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
      [<ffffffc0000bb40c>] kthread+0xe0/0xec
      
      -013|get_rps_cpu(
           |    dev = 0xFFFFFFC08B688000,
           |    skb = 0xFFFFFFC0C76AAC00 -> (
           |      dev = 0xFFFFFFC08B688000 -> (
           |        name =
      "......................................................
           |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
      0xAAAAAAAAAAA
      
      Following are the sequence of events observed -
      
      - Encrypted packet in receive path from netdevice is queued
      - Encrypted packet queued for decryption (asynchronous)
      - Netdevice brought down and freed
      - Packet is decrypted and returned through callback in esp_input_done
      - Packet is queued again for process in network stack using netif_rx
      
      Since the device appears to have been freed, the dereference of
      skb->dev in get_rps_cpus() leads to an unhandled page fault
      exception.
      
      Fix this by holding on to device reference when queueing packets
      asynchronously and releasing the reference on call back return.
      
      v2: Make the change generic to xfrm as mentioned by Steffen and
      update the title to xfrm
      Suggested-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJerome Stanislaus <jeromes@codeaurora.org>
      Signed-off-by: default avatarSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e1e03d36
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · 736a17fe
      Guillaume Nault authored
      [ Upstream commit 1f461dcd ]
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      736a17fe
    • Manish Chopra's avatar
      qlge: Fix receive packets drop. · ee9f959b
      Manish Chopra authored
      [ Upstream commit 2c9a266a ]
      
      When running small packets [length < 256 bytes] traffic, packets were
      being dropped due to invalid data in those packets which were
      delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
      ensures copying latest and updated data into skb from the receive buffer.
      Signed-off-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarManish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ee9f959b
    • Dmitri Epshtein's avatar
      net: mvneta: enable change MAC address when interface is up · 46e63be2
      Dmitri Epshtein authored
      [ Upstream commit 928b6519 ]
      
      Function eth_prepare_mac_addr_change() is called as part of MAC
      address change. This function check if interface is running.
      To enable change MAC address when interface is running:
      IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field
      
      Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP
      network unit")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitri Epshtein <dima@marvell.com>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      46e63be2
  4. 18 Apr, 2016 3 commits
    • Arnd Bergmann's avatar
      ath9k: fix buffer overrun for ar9287 · 13ee1c28
      Arnd Bergmann authored
      [ Upstream commit 83d6f1f1 ]
      
      Code that was added back in 2.6.38 has an obvious overflow
      when accessing a static array, and at the time it was added
      only a code comment was put in front of it as a reminder
      to have it reviewed properly.
      
      This has not happened, but gcc-6 now points to the specific
      overflow:
      
      drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
      drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
           maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
      
      It turns out that the correct array length exists in the local
      'intercepts' variable of this function, so we can just use that
      instead of hardcoding '4', so this patch changes all three
      instances to use that variable. The other two instances were
      already correct, but it's more consistent this way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 940cd2c1 ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      13ee1c28
    • Arnd Bergmann's avatar
      farsync: fix off-by-one bug in fst_add_one · 217dc642
      Arnd Bergmann authored
      [ Upstream commit e725a66c ]
      
      gcc-6 finds an out of bounds access in the fst_add_one function
      when calculating the end of the mmio area:
      
      drivers/net/wan/farsync.c: In function 'fst_add_one':
      drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                                           ^
      include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
        __builtin_offsetof(a, b)
                           ^
      drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                           ^~~~~~~~
      drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
                                        + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
                                          ^~~~~~~~~~
      
      The warning is correct, but not critical because this appears
      to be a write-only variable that is set by each WAN driver but
      never accessed afterwards.
      
      I'm taking the minimal fix here, using the correct pointer by
      pointing 'mem_end' to the last byte inside of the register area
      as all other WAN drivers do, rather than the first byte outside of
      it. An alternative would be to just remove the mem_end member
      entirely.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      217dc642
    • Arnd Bergmann's avatar
      mlx4: add missing braces in verify_qp_parameters · e58dc035
      Arnd Bergmann authored
      [ Upstream commit baefd701 ]
      
      The implementation of QP paravirtualization back in linux-3.7 included
      some code that looks very dubious, and gcc-6 has grown smart enough
      to warn about it:
      
      drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters':
      drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
           if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) {
           ^~
      drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not
          if (slave != mlx4_master_func_num(dev))
      
      >From looking at the context, I'm reasonably sure that the indentation
      is correct but that it should have contained curly braces from the
      start, as the update_gid() function in the same patch correctly does.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 54679e14 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e58dc035