<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/net, branch v3.9.7</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.9.7</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.9.7'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2013-06-20T19:01:28Z</updated>
<entry>
<title>Bluetooth: Fix mgmt handling of power on failures</title>
<updated>2013-06-20T19:01:28Z</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2013-05-29T06:51:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=15794d484f6404b4794867a0da892c01b20ccf24'/>
<id>urn:sha1:15794d484f6404b4794867a0da892c01b20ccf24</id>
<content type='text'>
commit 96570ffcca0b872dc8626e97569d2697f374d868 upstream.

If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Acked-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipv6: do not clear pinet6 field</title>
<updated>2013-05-19T18:38:38Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-05-09T10:28:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=285665993541f4f9d8bf80db6d7d27b205aa78b9'/>
<id>urn:sha1:285665993541f4f9d8bf80db6d7d27b205aa78b9</id>
<content type='text'>
[ Upstream commit f77d602124d865c38705df7fa25c03de9c284ad2 ]

We have seen multiple NULL dereferences in __inet6_lookup_established()

After analysis, I found that inet6_sk() could be NULL while the
check for sk_family == AF_INET6 was true.

Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
and TCP stacks.

Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
table, we no longer can clear pinet6 field.

This patch extends logic used in commit fcbdf09d9652c891
("net: fix nulls list corruptions in sk_prot_alloc")

TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
to make sure we do not clear pinet6 field.

At socket clone phase, we do not really care, as cloning the parent (non
NULL) pinet6 is not adding a fatal race.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: frag, fix race conditions in LRU list maintenance</title>
<updated>2013-05-19T18:38:37Z</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@openvz.org</email>
</author>
<published>2013-05-05T04:56:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=58484f8c691f3045528f2c488f35eb354e407bb7'/>
<id>urn:sha1:58484f8c691f3045528f2c488f35eb354e407bb7</id>
<content type='text'>
[ Upstream commit b56141ab34e2c3e2d7960cea12c20c99530c0c76 ]

This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add()
which was introduced in commit 3ef0eb0db4bf92c6d2510fe5c4dc51852746f206
("net: frag, move LRU list maintenance outside of rwlock")

One cpu already added new fragment queue into hash but not into LRU.
Other cpu found it in hash and tries to move it to the end of LRU.
This leads to NULL pointer dereference inside of list_move_tail().

Another possible race condition is between inet_frag_lru_move() and
inet_frag_lru_del(): move can happens after deletion.

This patch initializes LRU list head before adding fragment into hash and
inet_frag_lru_move() doesn't touches it if it's empty.

I saw this kernel oops two times in a couple of days.

[119482.128853] BUG: unable to handle kernel NULL pointer dereference at           (null)
[119482.132693] IP: [&lt;ffffffff812ede89&gt;] __list_del_entry+0x29/0xd0
[119482.136456] PGD 2148f6067 PUD 215ab9067 PMD 0
[119482.140221] Oops: 0000 [#1] SMP
[119482.144008] Modules linked in: vfat msdos fat 8021q fuse nfsd auth_rpcgss nfs_acl nfs lockd sunrpc ppp_async ppp_generic bridge slhc stp llc w83627ehf hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek kvm_amd k10temp kvm snd_hda_intel snd_hda_codec edac_core radeon snd_hwdep ath9k snd_pcm ath9k_common snd_page_alloc ath9k_hw snd_timer snd soundcore drm_kms_helper ath ttm r8169 mii
[119482.152692] CPU 3
[119482.152721] Pid: 20, comm: ksoftirqd/3 Not tainted 3.9.0-zurg-00001-g9f95269 #132 To Be Filled By O.E.M. To Be Filled By O.E.M./RS880D
[119482.161478] RIP: 0010:[&lt;ffffffff812ede89&gt;]  [&lt;ffffffff812ede89&gt;] __list_del_entry+0x29/0xd0
[119482.166004] RSP: 0018:ffff880216d5db58  EFLAGS: 00010207
[119482.170568] RAX: 0000000000000000 RBX: ffff88020882b9c0 RCX: dead000000200200
[119482.175189] RDX: 0000000000000000 RSI: 0000000000000880 RDI: ffff88020882ba00
[119482.179860] RBP: ffff880216d5db58 R08: ffffffff8155c7f0 R09: 0000000000000014
[119482.184570] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88020882ba00
[119482.189337] R13: ffffffff81c8d780 R14: ffff880204357f00 R15: 00000000000005a0
[119482.194140] FS:  00007f58124dc700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000
[119482.198928] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[119482.203711] CR2: 0000000000000000 CR3: 00000002155f0000 CR4: 00000000000007e0
[119482.208533] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[119482.213371] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[119482.218221] Process ksoftirqd/3 (pid: 20, threadinfo ffff880216d5c000, task ffff880216d3a9a0)
[119482.223113] Stack:
[119482.228004]  ffff880216d5dbd8 ffffffff8155dcda 0000000000000000 ffff000200000001
[119482.233038]  ffff8802153c1f00 ffff880000289440 ffff880200000014 ffff88007bc72000
[119482.238083]  00000000000079d5 ffff88007bc72f44 ffffffff00000002 ffff880204357f00
[119482.243090] Call Trace:
[119482.248009]  [&lt;ffffffff8155dcda&gt;] ip_defrag+0x8fa/0xd10
[119482.252921]  [&lt;ffffffff815a8013&gt;] ipv4_conntrack_defrag+0x83/0xe0
[119482.257803]  [&lt;ffffffff8154485b&gt;] nf_iterate+0x8b/0xa0
[119482.262658]  [&lt;ffffffff8155c7f0&gt;] ? inet_del_offload+0x40/0x40
[119482.267527]  [&lt;ffffffff815448e4&gt;] nf_hook_slow+0x74/0x130
[119482.272412]  [&lt;ffffffff8155c7f0&gt;] ? inet_del_offload+0x40/0x40
[119482.277302]  [&lt;ffffffff8155d068&gt;] ip_rcv+0x268/0x320
[119482.282147]  [&lt;ffffffff81519992&gt;] __netif_receive_skb_core+0x612/0x7e0
[119482.286998]  [&lt;ffffffff81519b78&gt;] __netif_receive_skb+0x18/0x60
[119482.291826]  [&lt;ffffffff8151a650&gt;] process_backlog+0xa0/0x160
[119482.296648]  [&lt;ffffffff81519f29&gt;] net_rx_action+0x139/0x220
[119482.301403]  [&lt;ffffffff81053707&gt;] __do_softirq+0xe7/0x220
[119482.306103]  [&lt;ffffffff81053868&gt;] run_ksoftirqd+0x28/0x40
[119482.310809]  [&lt;ffffffff81074f5f&gt;] smpboot_thread_fn+0xff/0x1a0
[119482.315515]  [&lt;ffffffff81074e60&gt;] ? lg_local_lock_cpu+0x40/0x40
[119482.320219]  [&lt;ffffffff8106d870&gt;] kthread+0xc0/0xd0
[119482.324858]  [&lt;ffffffff8106d7b0&gt;] ? insert_kthread_work+0x40/0x40
[119482.329460]  [&lt;ffffffff816c32dc&gt;] ret_from_fork+0x7c/0xb0
[119482.334057]  [&lt;ffffffff8106d7b0&gt;] ? insert_kthread_work+0x40/0x40
[119482.338661] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a &lt;4c&gt; 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08
[119482.343787] RIP  [&lt;ffffffff812ede89&gt;] __list_del_entry+0x29/0xd0
[119482.348675]  RSP &lt;ffff880216d5db58&gt;
[119482.353493] CR2: 0000000000000000

Oops happened on this path:
ip_defrag() -&gt; ip_frag_queue() -&gt; inet_frag_lru_move() -&gt; list_move_tail() -&gt; __list_del_entry()

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Cc: Jesper Dangaard Brouer &lt;brouer@redhat.com&gt;
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Jesper Dangaard Brouer &lt;brouer@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tcp: force a dst refcount when prequeue packet</title>
<updated>2013-05-19T18:38:33Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-04-25T01:34:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=756cecd0f066505c506b009235159b30a152d581'/>
<id>urn:sha1:756cecd0f066505c506b009235159b30a152d581</id>
<content type='text'>
[ Upstream commit 093162553c33e9479283e107b4431378271c735d ]

Before escaping RCU protected section and adding packet into
prequeue, make sure the dst is refcounted.

Reported-by: Mike Galbraith &lt;bitbucket@online.de&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: fix incorrect credentials passing</title>
<updated>2013-04-20T20:56:42Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-04-19T15:32:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=83f1b4ba917db5dc5a061a44b3403ddb6e783494'/>
<id>urn:sha1:83f1b4ba917db5dc5a061a44b3403ddb6e783494</id>
<content type='text'>
Commit 257b5358b32f ("scm: Capture the full credentials of the scm
sender") changed the credentials passing code to pass in the effective
uid/gid instead of the real uid/gid.

Obviously this doesn't matter most of the time (since normally they are
the same), but it results in differences for suid binaries when the wrong
uid/gid ends up being used.

This just undoes that (presumably unintentional) part of the commit.

Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Cc: Serge E. Hallyn &lt;serge@hallyn.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Acked-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>irda: small read past the end of array in debug code</title>
<updated>2013-04-19T21:32:31Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-04-16T21:10:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e15465e1808542743627f13d1c0cbb7eacc82b83'/>
<id>urn:sha1:e15465e1808542743627f13d1c0cbb7eacc82b83</id>
<content type='text'>
The "reason" can come from skb-&gt;data[] and it hasn't been capped so it
can be from 0-255 instead of just 0-6.  For example in irlmp_state_dtr()
the code does:

	reason = skb-&gt;data[3];
	...
	irlmp_disconnect_indication(self, reason, skb);

Also LMREASON has a couple other values which don't have entries in the
irlmp_reasons[] array.  And 0xff is a valid reason as well which means
"unknown".

So far as I can see we don't actually care about "reason" except for in
the debug code.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: statically link register_inet6addr_notifier()</title>
<updated>2013-04-14T19:24:17Z</updated>
<author>
<name>Cong Wang</name>
<email>amwang@redhat.com</email>
</author>
<published>2013-04-14T15:18:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f88c91ddba958e9a5dd4a5ee8c52a0faa790f586'/>
<id>urn:sha1:f88c91ddba958e9a5dd4a5ee8c52a0faa790f586</id>
<content type='text'>
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: Tomas Melin &lt;tomas.melin@iki.fi&gt;
Cc: Tomas Melin &lt;tomas.melin@iki.fi&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: YOSHIFUJI Hidaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Cong Wang &lt;amwang@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_iucv: fix recvmsg by replacing skb_pull() function</title>
<updated>2013-04-08T21:16:57Z</updated>
<author>
<name>Ursula Braun</name>
<email>ursula.braun@de.ibm.com</email>
</author>
<published>2013-04-07T22:19:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f9c41a62bba3f3f7ef3541b2a025e3371bcbba97'/>
<id>urn:sha1:f9c41a62bba3f3f7ef3541b2a025e3371bcbba97</id>
<content type='text'>
When receiving data messages, the "BUG_ON(skb-&gt;len &lt; skb-&gt;data_len)" in
the skb_pull() function triggers a kernel panic.

Replace the skb_pull logic by a per skb offset as advised by
Eric Dumazet.

Signed-off-by: Ursula Braun &lt;ursula.braun@de.ibm.com&gt;
Signed-off-by: Frank Blaschka &lt;blaschka@linux.vnet.ibm.com&gt;
Reviewed-by: Hendrik Brueckner &lt;brueckner@linux.vnet.ibm.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv4: Fix ip-header identification for gso packets.</title>
<updated>2013-03-26T17:50:05Z</updated>
<author>
<name>Pravin B Shelar</name>
<email>pshelar@nicira.com</email>
</author>
<published>2013-03-24T17:36:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=330305cc4a6b0cb75c22fc01b8826f0ad755550f'/>
<id>urn:sha1:330305cc4a6b0cb75c22fc01b8826f0ad755550f</id>
<content type='text'>
ip-header id needs to be incremented even if IP_DF flag is set.
This behaviour was changed in commit 490ab08127cebc25e3a26
(IP_GRE: Fix IP-Identification).

Following patch fixes it so that identification is always
incremented.

Reported-by: Cong Wang &lt;amwang@redhat.com&gt;
Signed-off-by: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>flow_keys: include thoff into flow_keys for later usage</title>
<updated>2013-03-20T16:14:36Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2013-03-19T06:39:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8ed781668dd49b608f1e67a22e3b445fd0c2cd6f'/>
<id>urn:sha1:8ed781668dd49b608f1e67a22e3b445fd0c2cd6f</id>
<content type='text'>
In skb_flow_dissect(), we perform a dissection of a skbuff. Since we're
doing the work here anyway, also store thoff for a later usage, e.g. in
the BPF filter.

Suggested-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
