<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/ipv6, branch v3.0.98</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO</title>
<updated>2013-09-14T12:50:48+00:00</updated>
<author>
<name>Jiri Bohac</name>
<email>jbohac@suse.cz</email>
</author>
<published>2013-08-30T09:18:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2eeeacf627ab4bac67c3c1735b2c96fccbea6262'/>
<id>2eeeacf627ab4bac67c3c1735b2c96fccbea6262</id>
<content type='text'>
[ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
unreachable) messages:
        5 - Source address failed ingress/egress policy
	6 - Reject route to destination

Now they are treated as protocol error and icmpv6_err_convert() converts them
to EPROTO.

RFC 4443 says:
	"Codes 5 and 6 are more informative subsets of code 1."

Treat codes 5 and 6 as code 1 (EACCES)

Btw, connect() returning -EPROTO confuses firefox, so that fallback to
other/IPv4 addresses does not work:
https://bugzilla.mozilla.org/show_bug.cgi?id=910773

Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
unreachable) messages:
        5 - Source address failed ingress/egress policy
	6 - Reject route to destination

Now they are treated as protocol error and icmpv6_err_convert() converts them
to EPROTO.

RFC 4443 says:
	"Codes 5 and 6 are more informative subsets of code 1."

Treat codes 5 and 6 as code 1 (EACCES)

Btw, connect() returning -EPROTO confuses firefox, so that fallback to
other/IPv4 addresses does not work:
https://bugzilla.mozilla.org/show_bug.cgi?id=910773

Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: Don't depend on per socket memory for neighbour discovery messages</title>
<updated>2013-09-14T12:50:48+00:00</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@suug.ch</email>
</author>
<published>2013-09-03T11:37:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6ca04e8fc4c799a55b011d489b71a5732a9ae8dd'/>
<id>6ca04e8fc4c799a55b011d489b71a5732a9ae8dd</id>
<content type='text'>
[ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

Allocating skbs when sending out neighbour discovery messages
currently uses sock_alloc_send_skb() based on a per net namespace
socket and thus share a socket wmem buffer space.

If a netdevice is temporarily unable to transmit due to carrier
loss or for other reasons, the queued up ndisc messages will cosnume
all of the wmem space and will thus prevent from any more skbs to
be allocated even for netdevices that are able to transmit packets.

The number of neighbour discovery messages sent is very limited,
use of alloc_skb() bypasses the socket wmem buffer size enforcement
while the manual call to skb_set_owner_w() maintains the socket
reference needed for the IPv6 output path.

This patch has orginally been posted by Eric Dumazet in a modified
form.

Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Tested-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

Allocating skbs when sending out neighbour discovery messages
currently uses sock_alloc_send_skb() based on a per net namespace
socket and thus share a socket wmem buffer space.

If a netdevice is temporarily unable to transmit due to carrier
loss or for other reasons, the queued up ndisc messages will cosnume
all of the wmem space and will thus prevent from any more skbs to
be allocated even for netdevices that are able to transmit packets.

The number of neighbour discovery messages sent is very limited,
use of alloc_skb() bypasses the socket wmem buffer size enforcement
while the manual call to skb_set_owner_w() maintains the socket
reference needed for the IPv6 output path.

This patch has orginally been posted by Eric Dumazet in a modified
form.

Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Tested-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: drop packets with multiple fragmentation headers</title>
<updated>2013-09-14T12:50:48+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-08-16T11:30:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1eeceae48fdc6e6fcb71403010ef5dd863b7ef2f'/>
<id>1eeceae48fdc6e6fcb71403010ef5dd863b7ef2f</id>
<content type='text'>
[ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

It is not allowed for an ipv6 packet to contain multiple fragmentation
headers. So discard packets which were already reassembled by
fragmentation logic and send back a parameter problem icmp.

The updates for RFC 6980 will come in later, I have to do a bit more
research here.

Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

It is not allowed for an ipv6 packet to contain multiple fragmentation
headers. So discard packets which were already reassembled by
fragmentation logic and send back a parameter problem icmp.

The updates for RFC 6980 will come in later, I have to do a bit more
research here.

Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: remove max_addresses check from ipv6_create_tempaddr</title>
<updated>2013-09-14T12:50:48+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-08-16T11:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b7bb7587b9165ad6325b2908a19849dbded3ce0'/>
<id>9b7bb7587b9165ad6325b2908a19849dbded3ce0</id>
<content type='text'>
[ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

Because of the max_addresses check attackers were able to disable privacy
extensions on an interface by creating enough autoconfigured addresses:

&lt;http://seclists.org/oss-sec/2012/q4/292&gt;

But the check is not actually needed: max_addresses protects the
kernel to install too many ipv6 addresses on an interface and guards
addrconf_prefix_rcv to install further addresses as soon as this limit
is reached. We only generate temporary addresses in direct response of
a new address showing up. As soon as we filled up the maximum number of
addresses of an interface, we stop installing more addresses and thus
also stop generating more temp addresses.

Even if the attacker tries to generate a lot of temporary addresses
by announcing a prefix and removing it again (lifetime == 0) we won't
install more temp addresses, because the temporary addresses do count
to the maximum number of addresses, thus we would stop installing new
autoconfigured addresses when the limit is reached.

This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
possible).

Thanks to Ding Tianhong to bring this topic up again.

Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Ding Tianhong &lt;dingtianhong@huawei.com&gt;
Cc: George Kargiotakis &lt;kargig@void.gr&gt;
Cc: P J P &lt;ppandit@redhat.com&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Acked-by: Ding Tianhong &lt;dingtianhong@huawei.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

Because of the max_addresses check attackers were able to disable privacy
extensions on an interface by creating enough autoconfigured addresses:

&lt;http://seclists.org/oss-sec/2012/q4/292&gt;

But the check is not actually needed: max_addresses protects the
kernel to install too many ipv6 addresses on an interface and guards
addrconf_prefix_rcv to install further addresses as soon as this limit
is reached. We only generate temporary addresses in direct response of
a new address showing up. As soon as we filled up the maximum number of
addresses of an interface, we stop installing more addresses and thus
also stop generating more temp addresses.

Even if the attacker tries to generate a lot of temporary addresses
by announcing a prefix and removing it again (lifetime == 0) we won't
install more temp addresses, because the temporary addresses do count
to the maximum number of addresses, thus we would stop installing new
autoconfigured addresses when the limit is reached.

This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
possible).

Thanks to Ding Tianhong to bring this topic up again.

Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Ding Tianhong &lt;dingtianhong@huawei.com&gt;
Cc: George Kargiotakis &lt;kargig@void.gr&gt;
Cc: P J P &lt;ppandit@redhat.com&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Acked-by: Ding Tianhong &lt;dingtianhong@huawei.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match</title>
<updated>2013-09-14T12:50:48+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-08-07T00:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=24e6771d4fce7c77b2569fa33131c871a2c5642e'/>
<id>24e6771d4fce7c77b2569fa33131c871a2c5642e</id>
<content type='text'>
[ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

In case a subtree did not match we currently stop backtracking and return
NULL (root table from fib_lookup). This could yield in invalid routing
table lookups when using subtrees.

Instead continue to backtrack until a valid subtree or node is found
and return this match.

Also remove unneeded NULL check.

Reported-by: Teco Boot &lt;teco@inf-net.nl&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David Lamparter &lt;equinox@diac24.net&gt;
Cc: &lt;boutier@pps.univ-paris-diderot.fr&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

In case a subtree did not match we currently stop backtracking and return
NULL (root table from fib_lookup). This could yield in invalid routing
table lookups when using subtrees.

Instead continue to backtrack until a valid subtree or node is found
and return this match.

Also remove unneeded NULL check.

Reported-by: Teco Boot &lt;teco@inf-net.nl&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David Lamparter &lt;equinox@diac24.net&gt;
Cc: &lt;boutier@pps.univ-paris-diderot.fr&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup</title>
<updated>2013-08-11T22:38:22+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-07-22T21:45:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c4a6cc62e1fe24ab8d3bfe653f7e872a7a5bcd8e'/>
<id>c4a6cc62e1fe24ab8d3bfe653f7e872a7a5bcd8e</id>
<content type='text'>
[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net-&gt;ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[&lt;ffffffffa0366b02&gt;]  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
Stack:
 ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
 [&lt;ffffffffa034d9d1&gt;] rawv6_close+0x21/0x40 [ipv6]
 [&lt;ffffffff815bdecb&gt;] inet_release+0xfb/0x220
 [&lt;ffffffff815bddf2&gt;] ? inet_release+0x22/0x220
 [&lt;ffffffffa032686f&gt;] inet6_release+0x3f/0x50 [ipv6]
 [&lt;ffffffff8151c1d9&gt;] sock_release+0x29/0xa0
 [&lt;ffffffff81525520&gt;] sk_release_kernel+0x30/0x70
 [&lt;ffffffffa034f14b&gt;] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [&lt;ffffffff8152fff9&gt;] ops_exit_list+0x39/0x60
 [&lt;ffffffff815306fb&gt;] cleanup_net+0xfb/0x1a0
 [&lt;ffffffff81075e3a&gt;] process_one_work+0x1da/0x610
 [&lt;ffffffff81075dc9&gt;] ? process_one_work+0x169/0x610
 [&lt;ffffffff81076390&gt;] worker_thread+0x120/0x3a0
 [&lt;ffffffff81076270&gt;] ? process_one_work+0x610/0x610
 [&lt;ffffffff8107da2e&gt;] kthread+0xee/0x100
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff8162a99c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 &lt;4c&gt; 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP &lt;ffff881039367bd8&gt;
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Tested-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net-&gt;ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[&lt;ffffffffa0366b02&gt;]  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
Stack:
 ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
 [&lt;ffffffffa034d9d1&gt;] rawv6_close+0x21/0x40 [ipv6]
 [&lt;ffffffff815bdecb&gt;] inet_release+0xfb/0x220
 [&lt;ffffffff815bddf2&gt;] ? inet_release+0x22/0x220
 [&lt;ffffffffa032686f&gt;] inet6_release+0x3f/0x50 [ipv6]
 [&lt;ffffffff8151c1d9&gt;] sock_release+0x29/0xa0
 [&lt;ffffffff81525520&gt;] sk_release_kernel+0x30/0x70
 [&lt;ffffffffa034f14b&gt;] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [&lt;ffffffff8152fff9&gt;] ops_exit_list+0x39/0x60
 [&lt;ffffffff815306fb&gt;] cleanup_net+0xfb/0x1a0
 [&lt;ffffffff81075e3a&gt;] process_one_work+0x1da/0x610
 [&lt;ffffffff81075dc9&gt;] ? process_one_work+0x169/0x610
 [&lt;ffffffff81076390&gt;] worker_thread+0x120/0x3a0
 [&lt;ffffffff81076270&gt;] ? process_one_work+0x610/0x610
 [&lt;ffffffff8107da2e&gt;] kthread+0xee/0x100
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff8162a99c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8107d940&gt;] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 &lt;4c&gt; 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [&lt;ffffffffa0366b02&gt;] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP &lt;ffff881039367bd8&gt;
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Tested-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: call udp_push_pending_frames when uncorking a socket with AF_INET pending data</title>
<updated>2013-07-28T23:18:39+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-07-01T18:21:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=639e5920a9ae14b1eefc44a8740f5d0f816adb9a'/>
<id>639e5920a9ae14b1eefc44a8740f5d0f816adb9a</id>
<content type='text'>
[ Upstream commit 8822b64a0fa64a5dd1dfcf837c5b0be83f8c05d1 ]

We accidentally call down to ip6_push_pending_frames when uncorking
pending AF_INET data on a ipv6 socket. This results in the following
splat (from Dave Jones):

skbuff: skb_under_panic: text:ffffffff816765f6 len:48 put:40 head:ffff88013deb6df0 data:ffff88013deb6dec tail:0x2c end:0xc0 dev:&lt;NULL&gt;
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:126!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: dccp_ipv4 dccp 8021q garp bridge stp dlci mpoa snd_seq_dummy sctp fuse hidp tun bnep nfnetlink scsi_transport_iscsi rfcomm can_raw can_bcm af_802154 appletalk caif_socket can caif ipt_ULOG x25 rose af_key pppoe pppox ipx phonet irda llc2 ppp_generic slhc p8023 psnap p8022 llc crc_ccitt atm bluetooth
+netrom ax25 nfc rfkill rds af_rxrpc coretemp hwmon kvm_intel kvm crc32c_intel snd_hda_codec_realtek ghash_clmulni_intel microcode pcspkr snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd pps_core soundcore xfs libcrc32c
CPU: 2 PID: 8095 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #37
task: ffff8801f52c2520 ti: ffff8801e6430000 task.ti: ffff8801e6430000
RIP: 0010:[&lt;ffffffff816e759c&gt;]  [&lt;ffffffff816e759c&gt;] skb_panic+0x63/0x65
RSP: 0018:ffff8801e6431de8  EFLAGS: 00010282
RAX: 0000000000000086 RBX: ffff8802353d3cc0 RCX: 0000000000000006
RDX: 0000000000003b90 RSI: ffff8801f52c2ca0 RDI: ffff8801f52c2520
RBP: ffff8801e6431e08 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022ea0c800
R13: ffff88022ea0cdf8 R14: ffff8802353ecb40 R15: ffffffff81cc7800
FS:  00007f5720a10740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000005862000 CR3: 000000022843c000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Stack:
 ffff88013deb6dec 000000000000002c 00000000000000c0 ffffffff81a3f6e4
 ffff8801e6431e18 ffffffff8159a9aa ffff8801e6431e90 ffffffff816765f6
 ffffffff810b756b 0000000700000002 ffff8801e6431e40 0000fea9292aa8c0
Call Trace:
 [&lt;ffffffff8159a9aa&gt;] skb_push+0x3a/0x40
 [&lt;ffffffff816765f6&gt;] ip6_push_pending_frames+0x1f6/0x4d0
 [&lt;ffffffff810b756b&gt;] ? mark_held_locks+0xbb/0x140
 [&lt;ffffffff81694919&gt;] udp_v6_push_pending_frames+0x2b9/0x3d0
 [&lt;ffffffff81694660&gt;] ? udplite_getfrag+0x20/0x20
 [&lt;ffffffff8162092a&gt;] udp_lib_setsockopt+0x1aa/0x1f0
 [&lt;ffffffff811cc5e7&gt;] ? fget_light+0x387/0x4f0
 [&lt;ffffffff816958a4&gt;] udpv6_setsockopt+0x34/0x40
 [&lt;ffffffff815949f4&gt;] sock_common_setsockopt+0x14/0x20
 [&lt;ffffffff81593c31&gt;] SyS_setsockopt+0x71/0xd0
 [&lt;ffffffff816f5d54&gt;] tracesys+0xdd/0xe2
Code: 00 00 48 89 44 24 10 8b 87 d8 00 00 00 48 89 44 24 08 48 8b 87 e8 00 00 00 48 c7 c7 c0 04 aa 81 48 89 04 24 31 c0 e8 e1 7e ff ff &lt;0f&gt; 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55
RIP  [&lt;ffffffff816e759c&gt;] skb_panic+0x63/0x65
 RSP &lt;ffff8801e6431de8&gt;

This patch adds a check if the pending data is of address family AF_INET
and directly calls udp_push_ending_frames from udp_v6_push_pending_frames
if that is the case.

This bug was found by Dave Jones with trinity.

(Also move the initialization of fl6 below the AF_INET check, even if
not strictly necessary.)

Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Dave Jones &lt;davej@redhat.com&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8822b64a0fa64a5dd1dfcf837c5b0be83f8c05d1 ]

We accidentally call down to ip6_push_pending_frames when uncorking
pending AF_INET data on a ipv6 socket. This results in the following
splat (from Dave Jones):

skbuff: skb_under_panic: text:ffffffff816765f6 len:48 put:40 head:ffff88013deb6df0 data:ffff88013deb6dec tail:0x2c end:0xc0 dev:&lt;NULL&gt;
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:126!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: dccp_ipv4 dccp 8021q garp bridge stp dlci mpoa snd_seq_dummy sctp fuse hidp tun bnep nfnetlink scsi_transport_iscsi rfcomm can_raw can_bcm af_802154 appletalk caif_socket can caif ipt_ULOG x25 rose af_key pppoe pppox ipx phonet irda llc2 ppp_generic slhc p8023 psnap p8022 llc crc_ccitt atm bluetooth
+netrom ax25 nfc rfkill rds af_rxrpc coretemp hwmon kvm_intel kvm crc32c_intel snd_hda_codec_realtek ghash_clmulni_intel microcode pcspkr snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd pps_core soundcore xfs libcrc32c
CPU: 2 PID: 8095 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #37
task: ffff8801f52c2520 ti: ffff8801e6430000 task.ti: ffff8801e6430000
RIP: 0010:[&lt;ffffffff816e759c&gt;]  [&lt;ffffffff816e759c&gt;] skb_panic+0x63/0x65
RSP: 0018:ffff8801e6431de8  EFLAGS: 00010282
RAX: 0000000000000086 RBX: ffff8802353d3cc0 RCX: 0000000000000006
RDX: 0000000000003b90 RSI: ffff8801f52c2ca0 RDI: ffff8801f52c2520
RBP: ffff8801e6431e08 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022ea0c800
R13: ffff88022ea0cdf8 R14: ffff8802353ecb40 R15: ffffffff81cc7800
FS:  00007f5720a10740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000005862000 CR3: 000000022843c000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Stack:
 ffff88013deb6dec 000000000000002c 00000000000000c0 ffffffff81a3f6e4
 ffff8801e6431e18 ffffffff8159a9aa ffff8801e6431e90 ffffffff816765f6
 ffffffff810b756b 0000000700000002 ffff8801e6431e40 0000fea9292aa8c0
Call Trace:
 [&lt;ffffffff8159a9aa&gt;] skb_push+0x3a/0x40
 [&lt;ffffffff816765f6&gt;] ip6_push_pending_frames+0x1f6/0x4d0
 [&lt;ffffffff810b756b&gt;] ? mark_held_locks+0xbb/0x140
 [&lt;ffffffff81694919&gt;] udp_v6_push_pending_frames+0x2b9/0x3d0
 [&lt;ffffffff81694660&gt;] ? udplite_getfrag+0x20/0x20
 [&lt;ffffffff8162092a&gt;] udp_lib_setsockopt+0x1aa/0x1f0
 [&lt;ffffffff811cc5e7&gt;] ? fget_light+0x387/0x4f0
 [&lt;ffffffff816958a4&gt;] udpv6_setsockopt+0x34/0x40
 [&lt;ffffffff815949f4&gt;] sock_common_setsockopt+0x14/0x20
 [&lt;ffffffff81593c31&gt;] SyS_setsockopt+0x71/0xd0
 [&lt;ffffffff816f5d54&gt;] tracesys+0xdd/0xe2
Code: 00 00 48 89 44 24 10 8b 87 d8 00 00 00 48 89 44 24 08 48 8b 87 e8 00 00 00 48 c7 c7 c0 04 aa 81 48 89 04 24 31 c0 e8 e1 7e ff ff &lt;0f&gt; 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55
RIP  [&lt;ffffffff816e759c&gt;] skb_panic+0x63/0x65
 RSP &lt;ffff8801e6431de8&gt;

This patch adds a check if the pending data is of address family AF_INET
and directly calls udp_push_ending_frames from udp_v6_push_pending_frames
if that is the case.

This bug was found by Dave Jones with trinity.

(Also move the initialization of fl6 below the AF_INET check, even if
not strictly necessary.)

Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Dave Jones &lt;davej@redhat.com&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6,mcast: always hold idev-&gt;lock before mca_lock</title>
<updated>2013-07-28T23:18:37+00:00</updated>
<author>
<name>Amerigo Wang</name>
<email>amwang@redhat.com</email>
</author>
<published>2013-06-29T13:30:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=52ef39eeff06aecc56266902bba6bf28891cabd3'/>
<id>52ef39eeff06aecc56266902bba6bf28891cabd3</id>
<content type='text'>
[ Upstream commit 8965779d2c0e6ab246c82a405236b1fb2adae6b2, with
  some bits from commit b7b1bfce0bb68bd8f6e62a28295922785cc63781
  ("ipv6: split duplicate address detection and router solicitation timer")
  to get the __ipv6_get_lladdr() used by this patch. ]

dingtianhong reported the following deadlock detected by lockdep:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.4.24.05-0.1-default #1 Not tainted
 -------------------------------------------------------
 ksoftirqd/0/3 is trying to acquire lock:
  (&amp;ndev-&gt;lock){+.+...}, at: [&lt;ffffffff8147f804&gt;] ipv6_get_lladdr+0x74/0x120

 but task is already holding lock:
  (&amp;mc-&gt;mca_lock){+.+...}, at: [&lt;ffffffff8149d130&gt;] mld_send_report+0x40/0x150

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mc-&gt;mca_lock){+.+...}:
        [&lt;ffffffff810a8027&gt;] validate_chain+0x637/0x730
        [&lt;ffffffff810a8417&gt;] __lock_acquire+0x2f7/0x500
        [&lt;ffffffff810a8734&gt;] lock_acquire+0x114/0x150
        [&lt;ffffffff814f691a&gt;] rt_spin_lock+0x4a/0x60
        [&lt;ffffffff8149e4bb&gt;] igmp6_group_added+0x3b/0x120
        [&lt;ffffffff8149e5d8&gt;] ipv6_mc_up+0x38/0x60
        [&lt;ffffffff81480a4d&gt;] ipv6_find_idev+0x3d/0x80
        [&lt;ffffffff81483175&gt;] addrconf_notify+0x3d5/0x4b0
        [&lt;ffffffff814fae3f&gt;] notifier_call_chain+0x3f/0x80
        [&lt;ffffffff81073471&gt;] raw_notifier_call_chain+0x11/0x20
        [&lt;ffffffff813d8722&gt;] call_netdevice_notifiers+0x32/0x60
        [&lt;ffffffff813d92d4&gt;] __dev_notify_flags+0x34/0x80
        [&lt;ffffffff813d9360&gt;] dev_change_flags+0x40/0x70
        [&lt;ffffffff813ea627&gt;] do_setlink+0x237/0x8a0
        [&lt;ffffffff813ebb6c&gt;] rtnl_newlink+0x3ec/0x600
        [&lt;ffffffff813eb4d0&gt;] rtnetlink_rcv_msg+0x160/0x310
        [&lt;ffffffff814040b9&gt;] netlink_rcv_skb+0x89/0xb0
        [&lt;ffffffff813eb357&gt;] rtnetlink_rcv+0x27/0x40
        [&lt;ffffffff81403e20&gt;] netlink_unicast+0x140/0x180
        [&lt;ffffffff81404a9e&gt;] netlink_sendmsg+0x33e/0x380
        [&lt;ffffffff813c4252&gt;] sock_sendmsg+0x112/0x130
        [&lt;ffffffff813c537e&gt;] __sys_sendmsg+0x44e/0x460
        [&lt;ffffffff813c5544&gt;] sys_sendmsg+0x44/0x70
        [&lt;ffffffff814feab9&gt;] system_call_fastpath+0x16/0x1b

 -&gt; #0 (&amp;ndev-&gt;lock){+.+...}:
        [&lt;ffffffff810a798e&gt;] check_prev_add+0x3de/0x440
        [&lt;ffffffff810a8027&gt;] validate_chain+0x637/0x730
        [&lt;ffffffff810a8417&gt;] __lock_acquire+0x2f7/0x500
        [&lt;ffffffff810a8734&gt;] lock_acquire+0x114/0x150
        [&lt;ffffffff814f6c82&gt;] rt_read_lock+0x42/0x60
        [&lt;ffffffff8147f804&gt;] ipv6_get_lladdr+0x74/0x120
        [&lt;ffffffff8149b036&gt;] mld_newpack+0xb6/0x160
        [&lt;ffffffff8149b18b&gt;] add_grhead+0xab/0xc0
        [&lt;ffffffff8149d03b&gt;] add_grec+0x3ab/0x460
        [&lt;ffffffff8149d14a&gt;] mld_send_report+0x5a/0x150
        [&lt;ffffffff8149f99e&gt;] igmp6_timer_handler+0x4e/0xb0
        [&lt;ffffffff8105705a&gt;] call_timer_fn+0xca/0x1d0
        [&lt;ffffffff81057b9f&gt;] run_timer_softirq+0x1df/0x2e0
        [&lt;ffffffff8104e8c7&gt;] handle_pending_softirqs+0xf7/0x1f0
        [&lt;ffffffff8104ea3b&gt;] __do_softirq_common+0x7b/0xf0
        [&lt;ffffffff8104f07f&gt;] __thread_do_softirq+0x1af/0x210
        [&lt;ffffffff8104f1c1&gt;] run_ksoftirqd+0xe1/0x1f0
        [&lt;ffffffff8106c7de&gt;] kthread+0xae/0xc0
        [&lt;ffffffff814fff74&gt;] kernel_thread_helper+0x4/0x10

actually we can just hold idev-&gt;lock before taking pmc-&gt;mca_lock,
and avoid taking idev-&gt;lock again when iterating idev-&gt;addr_list,
since the upper callers of mld_newpack() already take
read_lock_bh(&amp;idev-&gt;lock).

Reported-by: dingtianhong &lt;dingtianhong@huawei.com&gt;
Cc: dingtianhong &lt;dingtianhong@huawei.com&gt;
Cc: Hideaki YOSHIFUJI &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Tested-by: Ding Tianhong &lt;dingtianhong@huawei.com&gt;
Tested-by: Chen Weilong &lt;chenweilong@huawei.com&gt;
Signed-off-by: Cong Wang &lt;amwang@redhat.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8965779d2c0e6ab246c82a405236b1fb2adae6b2, with
  some bits from commit b7b1bfce0bb68bd8f6e62a28295922785cc63781
  ("ipv6: split duplicate address detection and router solicitation timer")
  to get the __ipv6_get_lladdr() used by this patch. ]

dingtianhong reported the following deadlock detected by lockdep:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.4.24.05-0.1-default #1 Not tainted
 -------------------------------------------------------
 ksoftirqd/0/3 is trying to acquire lock:
  (&amp;ndev-&gt;lock){+.+...}, at: [&lt;ffffffff8147f804&gt;] ipv6_get_lladdr+0x74/0x120

 but task is already holding lock:
  (&amp;mc-&gt;mca_lock){+.+...}, at: [&lt;ffffffff8149d130&gt;] mld_send_report+0x40/0x150

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mc-&gt;mca_lock){+.+...}:
        [&lt;ffffffff810a8027&gt;] validate_chain+0x637/0x730
        [&lt;ffffffff810a8417&gt;] __lock_acquire+0x2f7/0x500
        [&lt;ffffffff810a8734&gt;] lock_acquire+0x114/0x150
        [&lt;ffffffff814f691a&gt;] rt_spin_lock+0x4a/0x60
        [&lt;ffffffff8149e4bb&gt;] igmp6_group_added+0x3b/0x120
        [&lt;ffffffff8149e5d8&gt;] ipv6_mc_up+0x38/0x60
        [&lt;ffffffff81480a4d&gt;] ipv6_find_idev+0x3d/0x80
        [&lt;ffffffff81483175&gt;] addrconf_notify+0x3d5/0x4b0
        [&lt;ffffffff814fae3f&gt;] notifier_call_chain+0x3f/0x80
        [&lt;ffffffff81073471&gt;] raw_notifier_call_chain+0x11/0x20
        [&lt;ffffffff813d8722&gt;] call_netdevice_notifiers+0x32/0x60
        [&lt;ffffffff813d92d4&gt;] __dev_notify_flags+0x34/0x80
        [&lt;ffffffff813d9360&gt;] dev_change_flags+0x40/0x70
        [&lt;ffffffff813ea627&gt;] do_setlink+0x237/0x8a0
        [&lt;ffffffff813ebb6c&gt;] rtnl_newlink+0x3ec/0x600
        [&lt;ffffffff813eb4d0&gt;] rtnetlink_rcv_msg+0x160/0x310
        [&lt;ffffffff814040b9&gt;] netlink_rcv_skb+0x89/0xb0
        [&lt;ffffffff813eb357&gt;] rtnetlink_rcv+0x27/0x40
        [&lt;ffffffff81403e20&gt;] netlink_unicast+0x140/0x180
        [&lt;ffffffff81404a9e&gt;] netlink_sendmsg+0x33e/0x380
        [&lt;ffffffff813c4252&gt;] sock_sendmsg+0x112/0x130
        [&lt;ffffffff813c537e&gt;] __sys_sendmsg+0x44e/0x460
        [&lt;ffffffff813c5544&gt;] sys_sendmsg+0x44/0x70
        [&lt;ffffffff814feab9&gt;] system_call_fastpath+0x16/0x1b

 -&gt; #0 (&amp;ndev-&gt;lock){+.+...}:
        [&lt;ffffffff810a798e&gt;] check_prev_add+0x3de/0x440
        [&lt;ffffffff810a8027&gt;] validate_chain+0x637/0x730
        [&lt;ffffffff810a8417&gt;] __lock_acquire+0x2f7/0x500
        [&lt;ffffffff810a8734&gt;] lock_acquire+0x114/0x150
        [&lt;ffffffff814f6c82&gt;] rt_read_lock+0x42/0x60
        [&lt;ffffffff8147f804&gt;] ipv6_get_lladdr+0x74/0x120
        [&lt;ffffffff8149b036&gt;] mld_newpack+0xb6/0x160
        [&lt;ffffffff8149b18b&gt;] add_grhead+0xab/0xc0
        [&lt;ffffffff8149d03b&gt;] add_grec+0x3ab/0x460
        [&lt;ffffffff8149d14a&gt;] mld_send_report+0x5a/0x150
        [&lt;ffffffff8149f99e&gt;] igmp6_timer_handler+0x4e/0xb0
        [&lt;ffffffff8105705a&gt;] call_timer_fn+0xca/0x1d0
        [&lt;ffffffff81057b9f&gt;] run_timer_softirq+0x1df/0x2e0
        [&lt;ffffffff8104e8c7&gt;] handle_pending_softirqs+0xf7/0x1f0
        [&lt;ffffffff8104ea3b&gt;] __do_softirq_common+0x7b/0xf0
        [&lt;ffffffff8104f07f&gt;] __thread_do_softirq+0x1af/0x210
        [&lt;ffffffff8104f1c1&gt;] run_ksoftirqd+0xe1/0x1f0
        [&lt;ffffffff8106c7de&gt;] kthread+0xae/0xc0
        [&lt;ffffffff814fff74&gt;] kernel_thread_helper+0x4/0x10

actually we can just hold idev-&gt;lock before taking pmc-&gt;mca_lock,
and avoid taking idev-&gt;lock again when iterating idev-&gt;addr_list,
since the upper callers of mld_newpack() already take
read_lock_bh(&amp;idev-&gt;lock).

Reported-by: dingtianhong &lt;dingtianhong@huawei.com&gt;
Cc: dingtianhong &lt;dingtianhong@huawei.com&gt;
Cc: Hideaki YOSHIFUJI &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Tested-by: Ding Tianhong &lt;dingtianhong@huawei.com&gt;
Tested-by: Chen Weilong &lt;chenweilong@huawei.com&gt;
Signed-off-by: Cong Wang &lt;amwang@redhat.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: ip6_sk_dst_check() must not assume ipv6 dst</title>
<updated>2013-07-28T23:18:34+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-06-26T11:15:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7a4957b92965755a246b52c4721a6c9a47f5bf31'/>
<id>7a4957b92965755a246b52c4721a6c9a47f5bf31</id>
<content type='text'>
[ Upstream commit a963a37d384d71ad43b3e9e79d68d42fbe0901f3 ]

It's possible to use AF_INET6 sockets and to connect to an IPv4
destination. After this, socket dst cache is a pointer to a rtable,
not rt6_info.

ip6_sk_dst_check() should check the socket dst cache is IPv6, or else
various corruptions/crashes can happen.

Dave Jones can reproduce immediate crash with
trinity -q -l off -n -c sendmsg -c connect

With help from Hannes Frederic Sowa

Reported-by: Dave Jones &lt;davej@redhat.com&gt;
Reported-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a963a37d384d71ad43b3e9e79d68d42fbe0901f3 ]

It's possible to use AF_INET6 sockets and to connect to an IPv4
destination. After this, socket dst cache is a pointer to a rtable,
not rt6_info.

ip6_sk_dst_check() should check the socket dst cache is IPv6, or else
various corruptions/crashes can happen.

Dave Jones can reproduce immediate crash with
trinity -q -l off -n -c sendmsg -c connect

With help from Hannes Frederic Sowa

Reported-by: Dave Jones &lt;davej@redhat.com&gt;
Reported-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: don't call addrconf_dst_alloc again when enable lo</title>
<updated>2013-07-28T23:18:33+00:00</updated>
<author>
<name>Gao feng</name>
<email>gaofeng@cn.fujitsu.com</email>
</author>
<published>2013-06-16T03:14:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f9ebf8ce570a993023dd8bb20a7378f710bba4ac'/>
<id>f9ebf8ce570a993023dd8bb20a7378f710bba4ac</id>
<content type='text'>
[ Upstream commit a881ae1f625c599b460cc8f8a7fcb1c438f699ad ]

If we disable all of the net interfaces, and enable
un-lo interface before lo interface, we already allocated
the addrconf dst in ipv6_add_addr. So we shouldn't allocate
it again when we enable lo interface.

Otherwise the message below will be triggered.
unregister_netdevice: waiting for sit1 to become free. Usage count = 1

This problem is introduced by commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"

Signed-off-by: Gao feng &lt;gaofeng@cn.fujitsu.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a881ae1f625c599b460cc8f8a7fcb1c438f699ad ]

If we disable all of the net interfaces, and enable
un-lo interface before lo interface, we already allocated
the addrconf dst in ipv6_add_addr. So we shouldn't allocate
it again when we enable lo interface.

Otherwise the message below will be triggered.
unregister_netdevice: waiting for sit1 to become free. Usage count = 1

This problem is introduced by commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"

Signed-off-by: Gao feng &lt;gaofeng@cn.fujitsu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
