1. 21 Apr, 2016 7 commits
    • Willy Tarreau's avatar
      pipe: limit the per-user amount of pages allocated in pipes · 2a032e30
      Willy Tarreau authored
      commit 759c0114 upstream.
      
      On no-so-small systems, it is possible for a single process to cause an
      OOM condition by filling large pipes with data that are never read. A
      typical process filling 4000 pipes with 1 MB of data will use 4 GB of
      memory. On small systems it may be tricky to set the pipe max size to
      prevent this from happening.
      
      This patch makes it possible to enforce a per-user soft limit above
      which new pipes will be limited to a single page, effectively limiting
      them to 4 kB each, as well as a hard limit above which no new pipes may
      be created for this user. This has the effect of protecting the system
      against memory abuse without hurting other users, and still allowing
      pipes to work correctly though with less data at once.
      
      The limit are controlled by two new sysctls : pipe-user-pages-soft, and
      pipe-user-pages-hard. Both may be disabled by setting them to zero. The
      default soft limit allows the default number of FDs per process (1024)
      to create pipes of the default size (64kB), thus reaching a limit of 64MB
      before starting to create only smaller pipes. With 256 processes limited
      to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB =
      1084 MB of memory allocated for a user. The hard limit is disabled by
      default to avoid breaking existing applications that make intensive use
      of pipes (eg: for splicing).
      
      Reported-by: socketpair@gmail.com
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Mitigates: CVE-2013-4312 (Linux 2.0+)
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2a032e30
    • Chuck Lever's avatar
      SUNRPC: Fix large reads on NFS/RDMA · 62efb1f4
      Chuck Lever authored
      commit 2b7bbc96 upstream.
      
      After commit a11a2bf4, "SUNRPC: Optimise away unnecessary data moves
      in xdr_align_pages", Thu Aug 2 13:21:43 2012, READs larger than a
      few hundred bytes via NFS/RDMA no longer work.  This commit exposed
      a long-standing bug in rpcrdma_inline_fixup().
      
      I reproduce this with an rsize=4096 mount using the cthon04 basic
      tests.  Test 5 fails with an EIO error.
      
      For my reproducer, kernel log shows:
      
        NFS: server cheating in read reply: count 4096 > recvd 0
      
      rpcrdma_inline_fixup() is zeroing the xdr_stream::page_len field,
      and xdr_align_pages() is now returning that value to the READ XDR
      decoder function.
      
      That field is set up by xdr_inline_pages() by the READ XDR encoder
      function.  As far as I can tell, it is supposed to be left alone
      after that, as it describes the dimensions of the reply xdr_stream,
      not the contents of that stream.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68391Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      62efb1f4
    • Takashi Iwai's avatar
      ALSA: timer: Sync timer deletion at closing the system timer · 9a2fa0d4
      Takashi Iwai authored
      commit f146357f upstream.
      
      ALSA timer core framework has no sync point at stopping because it's
      called inside the spinlock.  Thus we need a sync point at close for
      avoiding the stray timer task.  This is simply done by implementing
      the close callback just calling del_timer_sync().  (It's harmless to
      call it unconditionally, as the core timer itself cares of the already
      deleted timer instance.)
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9a2fa0d4
    • Romain Izard's avatar
      mmc: Allow forward compatibility for eMMC · 6f6abe51
      Romain Izard authored
      commit 03a59437 upstream.
      
      As stated by the eMMC 5.0 specification, a chip should not be rejected
      only because of the revision stated in the EXT_CSD_REV field of the
      EXT_CSD register.
      
      Remove the control on this value, the control of the CSD_STRUCTURE field
      should be sufficient to reject future incompatible changes.
      Signed-off-by: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6f6abe51
    • Greg Thelen's avatar
      fs, seqfile: always allow oom killer · 8bb06e09
      Greg Thelen authored
      commit 0f930902 upstream.
      
      Since 5cec38ac ("fs, seq_file: fallback to vmalloc instead of oom kill
      processes") seq_buf_alloc() avoids calling the oom killer for PAGE_SIZE or
      smaller allocations; but larger allocations can use the oom killer via
      vmalloc().  Thus reads of small files can return ENOMEM, but larger files
      use the oom killer to avoid ENOMEM.
      
      The effect of this bug is that reads from /proc and other virtual
      filesystems can return ENOMEM instead of the preferred behavior - oom
      killing something (possibly the calling process).  I don't know of anyone
      except Google who has noticed the issue.
      
      I suspect the fix is more needed in smaller systems where there isn't any
      reclaimable memory.  But these seem like the kinds of systems which
      probably don't use the oom killer for production situations.
      
      Memory overcommit requires use of the oom killer to select a victim
      regardless of file size.
      
      Enable oom killer for small seq_buf_alloc() allocations.
      
      Fixes: 5cec38ac ("fs, seq_file: fallback to vmalloc instead of oom kill processes")
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8bb06e09
    • David Rientjes's avatar
      fs, seq_file: fallback to vmalloc instead of oom kill processes · ef2276fc
      David Rientjes authored
      commit 5cec38ac upstream.
      
      Since commit 058504ed ("fs/seq_file: fallback to vmalloc allocation"),
      seq_buf_alloc() falls back to vmalloc() when the kmalloc() for contiguous
      memory fails.  This was done to address order-4 slab allocations for
      reading /proc/stat on large machines and noticed because
      PAGE_ALLOC_COSTLY_ORDER < 4, so there is no infinite loop in the page
      allocator when allocating new slab for such high-order allocations.
      
      Contiguous memory isn't necessary for caller of seq_buf_alloc(), however.
      Other GFP_KERNEL high-order allocations that are <=
      PAGE_ALLOC_COSTLY_ORDER will simply loop forever in the page allocator and
      oom kill processes as a result.
      
      We don't want to kill processes so that we can allocate contiguous memory
      in situations when contiguous memory isn't necessary.
      
      This patch does the kmalloc() allocation with __GFP_NORETRY for high-order
      allocations.  This still utilizes memory compaction and direct reclaim in
      the allocation path, the only difference is that it will fail immediately
      instead of oom kill processes when out of memory.
      
      [akpm@linux-foundation.org: add comment]
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ef2276fc
    • Bjørn Mork's avatar
      cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind · f0592d35
      Bjørn Mork authored
      commit 4d06dd53 upstream.
      
      usbnet_link_change will call schedule_work and should be
      avoided if bind is failing. Otherwise we will end up with
      scheduled work referring to a netdev which has gone away.
      
      Instead of making the call conditional, we can just defer
      it to usbnet_probe, using the driver_info flag made for
      this purpose.
      
      Fixes: 8a34b0ae ("usbnet: cdc_ncm: apply usbnet_link_change")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f0592d35
  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 1 commit
    • 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