Skip to content

GitLab

Switch branch/tag
  1. 02 May, 2013 11 commits
  3. 19 Apr, 2013 4 commits
  5. 18 Apr, 2013 2 commits
  7. 17 Apr, 2013 2 commits
  9. 15 Apr, 2013 2 commits
  11. 14 Apr, 2013 1 commit
    • Cong Wang's avatar
      ipv6: statically link register_inet6addr_notifier() · f88c91dd
      Cong Wang authored 
      
Tomas reported the following build error:

net/built-in.o: In function `ieee80211_unregister_hw':
(.text+0x10f0e1): undefined reference to `unregister_inet6addr_notifier'
net/built-in.o: In function `ieee80211_register_hw':
(.text+0x10f610): undefined reference to `register_inet6addr_notifier'
make: *** [vmlinux] Error 1

when built IPv6 as a module.

So we have to statically link these symbols.
Reported-by: default avatarTomas Melin <tomas.melin@iki.fi>
Cc: Tomas Melin <tomas.melin@iki.fi>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: YOSHIFUJI Hidaki <yoshfuji@linux-ipv6.org>
Signed-off-by: default avatarCong Wang <amwang@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f88c91dd
  13. 12 Apr, 2013 2 commits
    • David Ward's avatar
      net/802/mrp: fix possible race condition when calling mrp_pdu_queue() · fb745e9a
      David Ward authored 
      
(Adapted from a very similar change to net/802/garp.c by Cong Wang.)

mrp_pdu_queue() should ways be called with the applicant spin lock.
mrp_uninit_applicant() only holds the rtnl lock which is not enough;
a race is possible because mrp_rcv() is called in BH context:

	mrp_rcv()
	  |->mrp_pdu_parse_msg()
	    |->mrp_pdu_parse_vecattr()
	      |->mrp_pdu_parse_vecattr_event()
	        |-> mrp_attr_event()
	          |-> mrp_pdu_append_vecattr_event()
	            |-> mrp_pdu_queue()

Cc: Cong Wang <amwang@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid Ward <david.ward@ll.mit.edu>
Acked-by: default avatarCong Wang <amwang@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb745e9a
    • Florian Westphal's avatar
      netfilter: nf_nat: fix race when unloading protocol modules · c2d421e1
      Florian Westphal authored 
      
following oops was reported:
RIP: 0010:[<ffffffffa03227f2>]  [<ffffffffa03227f2>] nf_nat_cleanup_conntrack+0x42/0x70 [nf_nat]
RSP: 0018:ffff880202c63d40  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801ac7bec28 RCX: ffff8801d0eedbe0
RDX: dead000000200200 RSI: 0000000000000011 RDI: ffffffffa03265b8
[..]
Call Trace:
 [..]
 [<ffffffffa02febed>] destroy_conntrack+0xbd/0x110 [nf_conntrack]

Happens when a conntrack timeout expires right after first part
of the nat cleanup has completed (bysrc hash removal), but before
part 2 has completed (re-initialization of nat area).

[ destroy callback tries to delete bysrc again ]

Patrick suggested to just remove the affected conntracks -- the
connections won't work properly anyway without nat transformation.

So, lets do that.
Reported-by: default avatarCAI Qian <caiqian@redhat.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Acked-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      c2d421e1
  15. 11 Apr, 2013 2 commits
  17. 10 Apr, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix cfg80211 interaction on auth/assoc request · 7b119dc0
      Johannes Berg authored 
      
If authentication (or association with FT) is requested by
userspace, mac80211 currently doesn't tell cfg80211 that it
disconnected from the AP. That leaves inconsistent state:
cfg80211 thinks it's connected while mac80211 thinks it's
not. Typically this won't last long, as soon as mac80211
reports the new association to cfg80211 the old one goes
away. If, however, the new authentication or association
doesn't succeed, then cfg80211 will forever think the old
one still exists and will refuse attempts to authenticate
or associate with the AP it thinks it's connected to.

Anders reported that this leads to it taking a very long
time to reconnect to a network, or never even succeeding.
I tested this with an AP hacked to never respond to auth
frames, and one that works, and with just those two the
system never recovers because one won't work and cfg80211
thinks it's connected to the other so refuses connections
to it.

To fix this, simply make mac80211 tell cfg80211 when it is
no longer connected to the old AP, while authenticating or
associating to a new one.

Cc: stable@vger.kernel.org
Reported-by: default avatarAnders Kaseorg <andersk@mit.edu>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7b119dc0
  19. 09 Apr, 2013 5 commits
  21. 08 Apr, 2013 5 commits
  23. 07 Apr, 2013 3 commits
    • Mathias Krause's avatar
      VSOCK: Fix missing msg_namelen update in vsock_stream_recvmsg() · d5e0d0f6
      Mathias Krause authored 
      
The code misses to update the msg_namelen member to 0 and therefore
makes net/socket.c leak the local, uninitialized sockaddr_storage
variable to userland -- 128 bytes of kernel stack memory.

Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: George Zhang <georgezhang@vmware.com>
Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d5e0d0f6
    • Mathias Krause's avatar
      VSOCK: vmci - fix possible info leak in vmci_transport_dgram_dequeue() · 680d04e0
      Mathias Krause authored 
      
In case we received no data on the call to skb_recv_datagram(), i.e.
skb->data is NULL, vmci_transport_dgram_dequeue() will return with 0
without updating msg_namelen leading to net/socket.c leaking the local,
uninitialized sockaddr_storage variable to userland -- 128 bytes of
kernel stack memory.

Fix this by moving the already existing msg_namelen assignment a few
lines above.

Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: George Zhang <georgezhang@vmware.com>
Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      680d04e0
    • Mathias Krause's avatar
      tipc: fix info leaks via msg_name in recv_msg/recv_stream · 60085c3d
      Mathias Krause authored 
      
The code in set_orig_addr() does not initialize all of the members of
struct sockaddr_tipc when filling the sockaddr info -- namely the union
is only partly filled. This will make recv_msg() and recv_stream() --
the only users of this function -- leak kernel stack memory as the
msg_name member is a local variable in net/socket.c.

Additionally to that both recv_msg() and recv_stream() fail to update
the msg_namelen member to 0 while otherwise returning with 0, i.e.
"success". This is the case for, e.g., non-blocking sockets. This will
lead to a 128 byte kernel stack leak in net/socket.c.

Fix the first issue by initializing the memory of the union with
memset(0). Fix the second one by setting msg_namelen to 0 early as it
will be updated later if we're going to fill the msg_name member.

Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60085c3d

Powered by Integricloud