1. 03 4月, 2015 3 次提交
  2. 01 4月, 2015 5 次提交
    • J
      mac80211: fix RX A-MPDU session reorder timer deletion · 788211d8
      Johannes Berg 提交于
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      788211d8
    • Y
      tipc: fix a slab object leak · 7e436905
      Ying Xue 提交于
      When remove TIPC module, there is a warning to remind us that a slab
      object is leaked like:
      
      root@localhost:~# rmmod tipc
      [   19.056226] =============================================================================
      [   19.057549] BUG TIPC (Not tainted): Objects remaining in TIPC on kmem_cache_close()
      [   19.058736] -----------------------------------------------------------------------------
      [   19.058736]
      [   19.060287] INFO: Slab 0xffffea0000519a00 objects=23 used=1 fp=0xffff880014668b00 flags=0x100000000004080
      [   19.061915] INFO: Object 0xffff880014668000 @offset=0
      [   19.062717] kmem_cache_destroy TIPC: Slab cache still has objects
      
      This is because the listening socket of TIPC topology server is not
      closed before TIPC proto handler is unregistered with proto_unregister().
      However, as the socket is closed in tipc_exit_net() which is called by
      unregister_pernet_subsys() during unregistering TIPC namespace operation,
      the warning can be eliminated if calling unregister_pernet_subsys() is
      moved before calling proto_unregister().
      
      Fixes: e05b31f4 ("tipc: make tipc socket support net namespace")
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e436905
    • E
      af_iucv: fix AF_IUCV sendmsg() errno · ed4ac422
      Eugene Crosser 提交于
      When sending over AF_IUCV socket, errno was incorrectly set to
      ENOMEM even when other values where appropriate, notably EAGAIN.
      With this patch, error indicator returned by sock_alloc_send_skb()
      is passed to the caller, rather than being overwritten with ENOMEM.
      Signed-off-by: NEugene Crosser <Eugene.Crosser@ru.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed4ac422
    • T
      openvswitch: Return vport module ref before destruction · fa2d8ff4
      Thomas Graf 提交于
      Return module reference before invoking the respective vport
      ->destroy() function. This is needed as ovs_vport_del() is not
      invoked inside an RCU read side critical section so the kfree
      can occur immediately before returning to ovs_vport_del().
      
      Returning the module reference before ->destroy() is safe because
      the module unregistration is blocked on ovs_lock which we hold
      while destroying the datapath.
      
      Fixes: 62b9c8d0 ("ovs: Turn vports with dependencies into separate modules")
      Reported-by: NPravin Shelar <pshelar@nicira.com>
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa2d8ff4
    • J
      sunrpc: make debugfs file creation failure non-fatal · f9c72d10
      Jeff Layton 提交于
      We currently have a problem that SELinux policy is being enforced when
      creating debugfs files. If a debugfs file is created as a side effect of
      doing some syscall, then that creation can fail if the SELinux policy
      for that process prevents it.
      
      This seems wrong. We don't do that for files under /proc, for instance,
      so Bruce has proposed a patch to fix that.
      
      While discussing that patch however, Greg K.H. stated:
      
          "No kernel code should care / fail if a debugfs function fails, so
           please fix up the sunrpc code first."
      
      This patch converts all of the sunrpc debugfs setup code to be void
      return functins, and the callers to not look for errors from those
      functions.
      
      This should allow rpc_clnt and rpc_xprt creation to work, even if the
      kernel fails to create debugfs files for some reason.
      
      Symptoms were failing krb5 mounts on systems using gss-proxy and
      selinux.
      
      Fixes: 388f0c77 "sunrpc: add a debugfs rpc_xprt directory..."
      Cc: stable@vger.kernel.org
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f9c72d10
  3. 30 3月, 2015 3 次提交
  4. 25 3月, 2015 2 次提交
    • D
      ipv6: Don't reduce hop limit for an interface · 6fd99094
      D.S. Ljungmark 提交于
      A local route may have a lower hop_limit set than global routes do.
      
      RFC 3756, Section 4.2.7, "Parameter Spoofing"
      
      >   1.  The attacker includes a Current Hop Limit of one or another small
      >       number which the attacker knows will cause legitimate packets to
      >       be dropped before they reach their destination.
      
      >   As an example, one possible approach to mitigate this threat is to
      >   ignore very small hop limits.  The nodes could implement a
      >   configurable minimum hop limit, and ignore attempts to set it below
      >   said limit.
      Signed-off-by: ND.S. Ljungmark <ljungmark@modio.se>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6fd99094
    • W
      net: use for_each_netdev_safe() in rtnl_group_changelink() · d079535d
      WANG Cong 提交于
      In case we move the whole dev group to another netns,
      we should call for_each_netdev_safe(), otherwise we get
      a soft lockup:
      
       NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ip:798]
       irq event stamp: 255424
       hardirqs last  enabled at (255423): [<ffffffff81a2aa95>] restore_args+0x0/0x30
       hardirqs last disabled at (255424): [<ffffffff81a2ad5a>] apic_timer_interrupt+0x6a/0x80
       softirqs last  enabled at (255422): [<ffffffff81079ebc>] __do_softirq+0x2c1/0x3a9
       softirqs last disabled at (255417): [<ffffffff8107a190>] irq_exit+0x41/0x95
       CPU: 0 PID: 798 Comm: ip Not tainted 4.0.0-rc4+ #881
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       task: ffff8800d1b88000 ti: ffff880119530000 task.ti: ffff880119530000
       RIP: 0010:[<ffffffff810cad11>]  [<ffffffff810cad11>] debug_lockdep_rcu_enabled+0x28/0x30
       RSP: 0018:ffff880119533778  EFLAGS: 00000246
       RAX: ffff8800d1b88000 RBX: 0000000000000002 RCX: 0000000000000038
       RDX: 0000000000000000 RSI: ffff8800d1b888c8 RDI: ffff8800d1b888c8
       RBP: ffff880119533778 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 000000000000b5c2 R12: 0000000000000246
       R13: ffff880119533708 R14: 00000000001d5a40 R15: ffff88011a7d5a40
       FS:  00007fc01315f740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007f367a120988 CR3: 000000011849c000 CR4: 00000000000007f0
       Stack:
        ffff880119533798 ffffffff811ac868 ffffffff811ac831 ffffffff811ac828
        ffff8801195337c8 ffffffff811ac8c9 ffff8801195339b0 ffff8801197633e0
        0000000000000000 ffff8801195339b0 ffff8801195337d8 ffffffff811ad2d7
       Call Trace:
        [<ffffffff811ac868>] rcu_read_lock+0x37/0x6e
        [<ffffffff811ac831>] ? rcu_read_unlock+0x5f/0x5f
        [<ffffffff811ac828>] ? rcu_read_unlock+0x56/0x5f
        [<ffffffff811ac8c9>] __fget+0x2a/0x7a
        [<ffffffff811ad2d7>] fget+0x13/0x15
        [<ffffffff811be732>] proc_ns_fget+0xe/0x38
        [<ffffffff817c7714>] get_net_ns_by_fd+0x11/0x59
        [<ffffffff817df359>] rtnl_link_get_net+0x33/0x3e
        [<ffffffff817df3d7>] do_setlink+0x73/0x87b
        [<ffffffff810b28ce>] ? trace_hardirqs_off+0xd/0xf
        [<ffffffff81a2aa95>] ? retint_restore_args+0xe/0xe
        [<ffffffff817e0301>] rtnl_newlink+0x40c/0x699
        [<ffffffff817dffe0>] ? rtnl_newlink+0xeb/0x699
        [<ffffffff81a29246>] ? _raw_spin_unlock+0x28/0x33
        [<ffffffff8143ed1e>] ? security_capable+0x18/0x1a
        [<ffffffff8107da51>] ? ns_capable+0x4d/0x65
        [<ffffffff817de5ce>] rtnetlink_rcv_msg+0x181/0x194
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de44d>] ? __rtnl_unlock+0x17/0x17
        [<ffffffff818327c6>] netlink_rcv_skb+0x4d/0x93
        [<ffffffff817de42f>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff81830f18>] netlink_unicast+0xcb/0x150
        [<ffffffff8183198e>] netlink_sendmsg+0x501/0x523
        [<ffffffff8115cba9>] ? might_fault+0x59/0xa9
        [<ffffffff817b5398>] ? copy_from_user+0x2a/0x2c
        [<ffffffff817b7b74>] sock_sendmsg+0x34/0x3c
        [<ffffffff817b7f6d>] ___sys_sendmsg+0x1b8/0x255
        [<ffffffff8115c5eb>] ? handle_pte_fault+0xbd5/0xd4a
        [<ffffffff8100a2b0>] ? native_sched_clock+0x35/0x37
        [<ffffffff8109e94b>] ? sched_clock_local+0x12/0x72
        [<ffffffff8109eb9c>] ? sched_clock_cpu+0x9e/0xb7
        [<ffffffff810cadbf>] ? rcu_read_lock_held+0x3b/0x3d
        [<ffffffff811ac1d8>] ? __fcheck_files+0x4c/0x58
        [<ffffffff811ac946>] ? __fget_light+0x2d/0x52
        [<ffffffff817b8adc>] __sys_sendmsg+0x42/0x60
        [<ffffffff817b8b0c>] SyS_sendmsg+0x12/0x1c
        [<ffffffff81a29e32>] system_call_fastpath+0x12/0x17
      
      Fixes: e7ed828f ("netlink: support setting devgroup parameters")
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d079535d
  5. 24 3月, 2015 1 次提交
  6. 23 3月, 2015 1 次提交
  7. 21 3月, 2015 5 次提交
  8. 20 3月, 2015 1 次提交
  9. 19 3月, 2015 1 次提交
    • P
      netfilter: restore rule tracing via nfnetlink_log · 4017a7ee
      Pablo Neira Ayuso 提交于
      Since fab4085f ("netfilter: log: nf_log_packet() as real unified
      interface"), the loginfo structure that is passed to nf_log_packet() is
      used to explicitly indicate the logger type you want to use.
      
      This is a problem for people tracing rules through nfnetlink_log since
      packets are always routed to the NF_LOG_TYPE logger after the
      aforementioned patch.
      
      We can fix this by removing the trace loginfo structures, but that still
      changes the log level from 4 to 5 for tracing messages and there may be
      someone relying on this outthere. So let's just introduce a new
      nf_log_trace() function that restores the former behaviour.
      Reported-by: NMarkus Kötter <koetter@rrzn.uni-hannover.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      4017a7ee
  10. 18 3月, 2015 3 次提交
    • D
      act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome · ced585c8
      Daniel Borkmann 提交于
      Revisiting commit d23b8ad8 ("tc: add BPF based action") with regards
      to eBPF support, I was thinking that it might be better to improve
      return semantics from a BPF program invoked through BPF_PROG_RUN().
      
      Currently, in case filter_res is 0, we overwrite the default action
      opcode with TC_ACT_SHOT. A default action opcode configured through tc's
      m_bpf can be: TC_ACT_RECLASSIFY, TC_ACT_PIPE, TC_ACT_SHOT, TC_ACT_UNSPEC,
      TC_ACT_OK.
      
      In cls_bpf, we have the possibility to overwrite the default class
      associated with the classifier in case filter_res is _not_ 0xffffffff
      (-1).
      
      That allows us to fold multiple [e]BPF programs into a single one, where
      they would otherwise need to be defined as a separate classifier with
      its own classid, needlessly redoing parsing work, etc.
      
      Similarly, we could do better in act_bpf: Since above TC_ACT* opcodes
      are exported to UAPI anyway, we reuse them for return-code-to-tc-opcode
      mapping, where we would allow above possibilities. Thus, like in cls_bpf,
      a filter_res of 0xffffffff (-1) means that the configured _default_ action
      is used. Any unkown return code from the BPF program would fail in
      tcf_bpf() with TC_ACT_UNSPEC.
      
      Should we one day want to make use of TC_ACT_STOLEN or TC_ACT_QUEUED,
      which both have the same semantics, we have the option to either use
      that as a default action (filter_res of 0xffffffff) or non-default BPF
      return code.
      
      All that will allow us to transparently use tcf_bpf() for both BPF
      flavours.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ced585c8
    • E
      inet: Clean up inet_csk_wait_for_connect() vs. might_sleep() · cb7cf8a3
      Eric Dumazet 提交于
      I got the following trace with current net-next kernel :
      
      [14723.885290] WARNING: CPU: 26 PID: 22658 at kernel/sched/core.c:7285 __might_sleep+0x89/0xa0()
      [14723.885325] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810e8734>] prepare_to_wait_exclusive+0x34/0xa0
      [14723.885355] CPU: 26 PID: 22658 Comm: netserver Not tainted 4.0.0-dbg-DEV #1379
      [14723.885359]  ffffffff81a223a8 ffff881fae9e7ca8 ffffffff81650b5d 0000000000000001
      [14723.885364]  ffff881fae9e7cf8 ffff881fae9e7ce8 ffffffff810a72e7 0000000000000000
      [14723.885367]  ffffffff81a57620 000000000000093a 0000000000000000 ffff881fae9e7e64
      [14723.885371] Call Trace:
      [14723.885377]  [<ffffffff81650b5d>] dump_stack+0x4c/0x65
      [14723.885382]  [<ffffffff810a72e7>] warn_slowpath_common+0x97/0xe0
      [14723.885386]  [<ffffffff810a73e6>] warn_slowpath_fmt+0x46/0x50
      [14723.885390]  [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0
      [14723.885393]  [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0
      [14723.885396]  [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0
      [14723.885399]  [<ffffffff810ccdc9>] __might_sleep+0x89/0xa0
      [14723.885403]  [<ffffffff81581846>] lock_sock_nested+0x36/0xb0
      [14723.885406]  [<ffffffff815829a3>] ? release_sock+0x173/0x1c0
      [14723.885411]  [<ffffffff815ea1f7>] inet_csk_accept+0x157/0x2a0
      [14723.885415]  [<ffffffff810e8900>] ? abort_exclusive_wait+0xc0/0xc0
      [14723.885419]  [<ffffffff8161b96d>] inet_accept+0x2d/0x150
      [14723.885424]  [<ffffffff8157db6f>] SYSC_accept4+0xff/0x210
      [14723.885428]  [<ffffffff8165a451>] ? retint_swapgs+0xe/0x44
      [14723.885431]  [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0
      [14723.885437]  [<ffffffff81369c0e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [14723.885441]  [<ffffffff8157ef40>] SyS_accept+0x10/0x20
      [14723.885444]  [<ffffffff81659872>] system_call_fastpath+0x12/0x17
      [14723.885447] ---[ end trace ff74cd83355b1873 ]---
      
      In commit 26cabd31
      Peter added a sched_annotate_sleep() in sk_wait_event()
      
      Is the following patch needed as well ?
      
      Alternative would be to use sk_wait_event() from inet_csk_wait_for_connect()
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb7cf8a3
    • N
      ip6_tunnel: fix error code when tunnel exists · 37355565
      Nicolas Dichtel 提交于
      After commit 2b0bb01b, the kernel returns -ENOBUFS when user tries to add
      an existing tunnel with ioctl API:
      $ ip -6 tunnel add ip6tnl1 mode ip6ip6 dev eth1
      add tunnel "ip6tnl0" failed: No buffer space available
      
      It's confusing, the right error is EEXIST.
      
      This patch also change a bit the code returned:
       - ENOBUFS -> ENOMEM
       - ENOENT -> ENODEV
      
      Fixes: 2b0bb01b ("ip6_tunnel: Return an error when adding an existing tunnel.")
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      Reported-by: NPierre Cheynier <me@pierre-cheynier.net>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37355565
  11. 17 3月, 2015 1 次提交
  12. 16 3月, 2015 6 次提交
  13. 15 3月, 2015 1 次提交
  14. 14 3月, 2015 1 次提交
  15. 13 3月, 2015 2 次提交
  16. 12 3月, 2015 4 次提交