<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/core, branch v3.19.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: sysctl_net_core: check SNDBUF and RCVBUF for min length</title>
<updated>2015-03-26T12:59:33+00:00</updated>
<author>
<name>Alexey Kodanev</name>
<email>alexey.kodanev@oracle.com</email>
</author>
<published>2015-03-11T11:29:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e7778e3b37fa5f45aeaf1fb6ba6b1ec3854d0b3'/>
<id>1e7778e3b37fa5f45aeaf1fb6ba6b1ec3854d0b3</id>
<content type='text'>
[ Upstream commit b1cb59cf2efe7971d3d72a7b963d09a512d994c9 ]

sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be
set to incorrect values. Given that 'struct sk_buff' allocates from
rcvbuf, incorrectly set buffer length could result to memory
allocation failures. For example, set them as follows:

    # sysctl net.core.rmem_default=64
      net.core.wmem_default = 64
    # sysctl net.core.wmem_default=64
      net.core.wmem_default = 64
    # ping localhost -s 1024 -i 0 &gt; /dev/null

This could result to the following failure:

skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32
head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev:&lt;NULL&gt;
kernel BUG at net/core/skbuff.c:102!
invalid opcode: 0000 [#1] SMP
...
task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000
RIP: 0010:[&lt;ffffffff8155fbd1&gt;]  [&lt;ffffffff8155fbd1&gt;] skb_put+0xa1/0xb0
RSP: 0018:ffff88003ae8bc68  EFLAGS: 00010296
RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000
RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8
RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900
FS:  00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0
Stack:
 ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d
 ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550
 ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00
Call Trace:
 [&lt;ffffffff81628db4&gt;] unix_stream_sendmsg+0x2c4/0x470
 [&lt;ffffffff81556f56&gt;] sock_write_iter+0x146/0x160
 [&lt;ffffffff811d9612&gt;] new_sync_write+0x92/0xd0
 [&lt;ffffffff811d9cd6&gt;] vfs_write+0xd6/0x180
 [&lt;ffffffff811da499&gt;] SyS_write+0x59/0xd0
 [&lt;ffffffff81651532&gt;] system_call_fastpath+0x12/0x17
Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00
      00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 &lt;0f&gt; 0b
      eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83
RIP  [&lt;ffffffff8155fbd1&gt;] skb_put+0xa1/0xb0
RSP &lt;ffff88003ae8bc68&gt;
Kernel panic - not syncing: Fatal exception

Moreover, the possible minimum is 1, so we can get another kernel panic:
...
BUG: unable to handle kernel paging request at ffff88013caee5c0
IP: [&lt;ffffffff815604cf&gt;] __alloc_skb+0x12f/0x1f0
...

Signed-off-by: Alexey Kodanev &lt;alexey.kodanev@oracle.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 b1cb59cf2efe7971d3d72a7b963d09a512d994c9 ]

sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be
set to incorrect values. Given that 'struct sk_buff' allocates from
rcvbuf, incorrectly set buffer length could result to memory
allocation failures. For example, set them as follows:

    # sysctl net.core.rmem_default=64
      net.core.wmem_default = 64
    # sysctl net.core.wmem_default=64
      net.core.wmem_default = 64
    # ping localhost -s 1024 -i 0 &gt; /dev/null

This could result to the following failure:

skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32
head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev:&lt;NULL&gt;
kernel BUG at net/core/skbuff.c:102!
invalid opcode: 0000 [#1] SMP
...
task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000
RIP: 0010:[&lt;ffffffff8155fbd1&gt;]  [&lt;ffffffff8155fbd1&gt;] skb_put+0xa1/0xb0
RSP: 0018:ffff88003ae8bc68  EFLAGS: 00010296
RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000
RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8
RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900
FS:  00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0
Stack:
 ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d
 ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550
 ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00
Call Trace:
 [&lt;ffffffff81628db4&gt;] unix_stream_sendmsg+0x2c4/0x470
 [&lt;ffffffff81556f56&gt;] sock_write_iter+0x146/0x160
 [&lt;ffffffff811d9612&gt;] new_sync_write+0x92/0xd0
 [&lt;ffffffff811d9cd6&gt;] vfs_write+0xd6/0x180
 [&lt;ffffffff811da499&gt;] SyS_write+0x59/0xd0
 [&lt;ffffffff81651532&gt;] system_call_fastpath+0x12/0x17
Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00
      00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 &lt;0f&gt; 0b
      eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83
RIP  [&lt;ffffffff8155fbd1&gt;] skb_put+0xa1/0xb0
RSP &lt;ffff88003ae8bc68&gt;
Kernel panic - not syncing: Fatal exception

Moreover, the possible minimum is 1, so we can get another kernel panic:
...
BUG: unable to handle kernel paging request at ffff88013caee5c0
IP: [&lt;ffffffff815604cf&gt;] __alloc_skb+0x12f/0x1f0
...

Signed-off-by: Alexey Kodanev &lt;alexey.kodanev@oracle.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>net: do not use rcu in rtnl_dump_ifinfo()</title>
<updated>2015-03-18T13:10:51+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-02-27T17:42:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=25ba5bb0d71737c85ba2bb3b63069ef751396814'/>
<id>25ba5bb0d71737c85ba2bb3b63069ef751396814</id>
<content type='text'>
[ Upstream commit cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ]

We did a failed attempt in the past to only use rcu in rtnl dump
operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during
netlink dump callbacks")

Now that dumps are holding RTNL anyway, there is no need to also
use rcu locking, as it forbids any scheduling ability, like
GFP_KERNEL allocations that controlling path should use instead
of GFP_ATOMIC whenever possible.

This should fix following splat Cong Wang reported :

 [ INFO: suspicious RCU usage. ]
 3.19.0+ #805 Tainted: G        W

 include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 2 locks held by ip/771:
  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff8182b8f4&gt;] netlink_dump+0x21/0x26c
  #1:  (rcu_read_lock){......}, at: [&lt;ffffffff817d785b&gt;] rcu_read_lock+0x0/0x6e

 stack backtrace:
 CPU: 3 PID: 771 Comm: ip Tainted: G        W       3.19.0+ #805
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6
  ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd
  00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758
 Call Trace:
  [&lt;ffffffff81a27457&gt;] dump_stack+0x4c/0x65
  [&lt;ffffffff810b539b&gt;] lockdep_rcu_suspicious+0x107/0x110
  [&lt;ffffffff8109796f&gt;] rcu_preempt_sleep_check+0x45/0x47
  [&lt;ffffffff8109e457&gt;] ___might_sleep+0x1d/0x1cb
  [&lt;ffffffff8109e67d&gt;] __might_sleep+0x78/0x80
  [&lt;ffffffff814b9b1f&gt;] idr_alloc+0x45/0xd1
  [&lt;ffffffff810cb7ab&gt;] ? rcu_read_lock_held+0x3b/0x3d
  [&lt;ffffffff814b9f9d&gt;] ? idr_for_each+0x53/0x101
  [&lt;ffffffff817c1383&gt;] alloc_netid+0x61/0x69
  [&lt;ffffffff817c14c3&gt;] __peernet2id+0x79/0x8d
  [&lt;ffffffff817c1ab7&gt;] peernet2id+0x13/0x1f
  [&lt;ffffffff817d8673&gt;] rtnl_fill_ifinfo+0xa8d/0xc20
  [&lt;ffffffff810b17d9&gt;] ? __lock_is_held+0x39/0x52
  [&lt;ffffffff817d894f&gt;] rtnl_dump_ifinfo+0x149/0x213
  [&lt;ffffffff8182b9c2&gt;] netlink_dump+0xef/0x26c
  [&lt;ffffffff8182bcba&gt;] netlink_recvmsg+0x17b/0x2c5
  [&lt;ffffffff817b0adc&gt;] __sock_recvmsg+0x4e/0x59
  [&lt;ffffffff817b1b40&gt;] sock_recvmsg+0x3f/0x51
  [&lt;ffffffff817b1f9a&gt;] ___sys_recvmsg+0xf6/0x1d9
  [&lt;ffffffff8115dc67&gt;] ? handle_pte_fault+0x6e1/0xd3d
  [&lt;ffffffff8100a3a0&gt;] ? native_sched_clock+0x35/0x37
  [&lt;ffffffff8109f45b&gt;] ? sched_clock_local+0x12/0x72
  [&lt;ffffffff8109f6ac&gt;] ? sched_clock_cpu+0x9e/0xb7
  [&lt;ffffffff810cb7ab&gt;] ? rcu_read_lock_held+0x3b/0x3d
  [&lt;ffffffff811abde8&gt;] ? __fcheck_files+0x4c/0x58
  [&lt;ffffffff811ac556&gt;] ? __fget_light+0x2d/0x52
  [&lt;ffffffff817b376f&gt;] __sys_recvmsg+0x42/0x60
  [&lt;ffffffff817b379f&gt;] SyS_recvmsg+0x12/0x1c

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids")
Cc: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Reported-by: Cong Wang &lt;xiyou.wangcong@gmail.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 cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ]

We did a failed attempt in the past to only use rcu in rtnl dump
operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during
netlink dump callbacks")

Now that dumps are holding RTNL anyway, there is no need to also
use rcu locking, as it forbids any scheduling ability, like
GFP_KERNEL allocations that controlling path should use instead
of GFP_ATOMIC whenever possible.

This should fix following splat Cong Wang reported :

 [ INFO: suspicious RCU usage. ]
 3.19.0+ #805 Tainted: G        W

 include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 2 locks held by ip/771:
  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff8182b8f4&gt;] netlink_dump+0x21/0x26c
  #1:  (rcu_read_lock){......}, at: [&lt;ffffffff817d785b&gt;] rcu_read_lock+0x0/0x6e

 stack backtrace:
 CPU: 3 PID: 771 Comm: ip Tainted: G        W       3.19.0+ #805
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6
  ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd
  00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758
 Call Trace:
  [&lt;ffffffff81a27457&gt;] dump_stack+0x4c/0x65
  [&lt;ffffffff810b539b&gt;] lockdep_rcu_suspicious+0x107/0x110
  [&lt;ffffffff8109796f&gt;] rcu_preempt_sleep_check+0x45/0x47
  [&lt;ffffffff8109e457&gt;] ___might_sleep+0x1d/0x1cb
  [&lt;ffffffff8109e67d&gt;] __might_sleep+0x78/0x80
  [&lt;ffffffff814b9b1f&gt;] idr_alloc+0x45/0xd1
  [&lt;ffffffff810cb7ab&gt;] ? rcu_read_lock_held+0x3b/0x3d
  [&lt;ffffffff814b9f9d&gt;] ? idr_for_each+0x53/0x101
  [&lt;ffffffff817c1383&gt;] alloc_netid+0x61/0x69
  [&lt;ffffffff817c14c3&gt;] __peernet2id+0x79/0x8d
  [&lt;ffffffff817c1ab7&gt;] peernet2id+0x13/0x1f
  [&lt;ffffffff817d8673&gt;] rtnl_fill_ifinfo+0xa8d/0xc20
  [&lt;ffffffff810b17d9&gt;] ? __lock_is_held+0x39/0x52
  [&lt;ffffffff817d894f&gt;] rtnl_dump_ifinfo+0x149/0x213
  [&lt;ffffffff8182b9c2&gt;] netlink_dump+0xef/0x26c
  [&lt;ffffffff8182bcba&gt;] netlink_recvmsg+0x17b/0x2c5
  [&lt;ffffffff817b0adc&gt;] __sock_recvmsg+0x4e/0x59
  [&lt;ffffffff817b1b40&gt;] sock_recvmsg+0x3f/0x51
  [&lt;ffffffff817b1f9a&gt;] ___sys_recvmsg+0xf6/0x1d9
  [&lt;ffffffff8115dc67&gt;] ? handle_pte_fault+0x6e1/0xd3d
  [&lt;ffffffff8100a3a0&gt;] ? native_sched_clock+0x35/0x37
  [&lt;ffffffff8109f45b&gt;] ? sched_clock_local+0x12/0x72
  [&lt;ffffffff8109f6ac&gt;] ? sched_clock_cpu+0x9e/0xb7
  [&lt;ffffffff810cb7ab&gt;] ? rcu_read_lock_held+0x3b/0x3d
  [&lt;ffffffff811abde8&gt;] ? __fcheck_files+0x4c/0x58
  [&lt;ffffffff811ac556&gt;] ? __fget_light+0x2d/0x52
  [&lt;ffffffff817b376f&gt;] __sys_recvmsg+0x42/0x60
  [&lt;ffffffff817b379f&gt;] SyS_recvmsg+0x12/0x1c

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids")
Cc: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Reported-by: Cong Wang &lt;xiyou.wangcong@gmail.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>net: pktgen: disable xmit_clone on virtual devices</title>
<updated>2015-03-18T13:10:50+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-02-23T01:03:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=37c63bf5b692b8311722b3b64c9d7fe0022d43bf'/>
<id>37c63bf5b692b8311722b3b64c9d7fe0022d43bf</id>
<content type='text'>
[ Upstream commit 52d6c8c6ca125872459054daa70f2f1c698c8e75 ]

Trying to use burst capability (aka xmit_more) on a virtual device
like bonding is not supported.

For example, skb might be queued multiple times on a qdisc, with
various list corruptions.

Fixes: 38b2cf2982dc ("net: pktgen: packet bursting via skb-&gt;xmit_more")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@plumgrid.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 52d6c8c6ca125872459054daa70f2f1c698c8e75 ]

Trying to use burst capability (aka xmit_more) on a virtual device
like bonding is not supported.

For example, skb might be queued multiple times on a qdisc, with
various list corruptions.

Fixes: 38b2cf2982dc ("net: pktgen: packet bursting via skb-&gt;xmit_more")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@plumgrid.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>net: reject creation of netdev names with colons</title>
<updated>2015-03-18T13:10:50+00:00</updated>
<author>
<name>Matthew Thode</name>
<email>mthode@mthode.org</email>
</author>
<published>2015-02-18T00:31:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=465146d28c3173d31229df1cf53a4696360a399d'/>
<id>465146d28c3173d31229df1cf53a4696360a399d</id>
<content type='text'>
[ Upstream commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ]

colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode &lt;mthode@mthode.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 a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ]

colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode &lt;mthode@mthode.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>sock: sock_dequeue_err_skb() needs hard irq safety</title>
<updated>2015-03-18T13:10:50+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-02-18T13:47:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d0ba3cf285bc815de7d4cf3fc2bf9fe4d4e5c5c'/>
<id>9d0ba3cf285bc815de7d4cf3fc2bf9fe4d4e5c5c</id>
<content type='text'>
[ Upstream commit 997d5c3f4427f38562cbe207ce05bb25fdcb993b ]

Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb()
from hard IRQ context.

Therefore, sock_dequeue_err_skb() needs to block hard irq or
corruptions or hangs can happen.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Fixes: 364a9e93243d1 ("sock: deduplicate errqueue dequeue")
Fixes: cb820f8e4b7f7 ("net: Provide a generic socket error queue delivery method for Tx time stamps.")
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 997d5c3f4427f38562cbe207ce05bb25fdcb993b ]

Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb()
from hard IRQ context.

Therefore, sock_dequeue_err_skb() needs to block hard irq or
corruptions or hangs can happen.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Fixes: 364a9e93243d1 ("sock: deduplicate errqueue dequeue")
Fixes: cb820f8e4b7f7 ("net: Provide a generic socket error queue delivery method for Tx time stamps.")
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>gen_stats.c: Duplicate xstats buffer for later use</title>
<updated>2015-03-18T13:10:49+00:00</updated>
<author>
<name>Ignacy Gawędzki</name>
<email>ignacy.gawedzki@green-communications.fr</email>
</author>
<published>2015-02-13T22:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e67e4522676c60772d3bf476bfbf99fd7d4c1aca'/>
<id>e67e4522676c60772d3bf476bfbf99fd7d4c1aca</id>
<content type='text'>
[ Upstream commit 1c4cff0cf55011792125b6041bc4e9713e46240f ]

The gnet_stats_copy_app() function gets called, more often than not, with its
second argument a pointer to an automatic variable in the caller's stack.
Therefore, to avoid copying garbage afterwards when calling
gnet_stats_finish_copy(), this data is better copied to a dynamically allocated
memory that gets freed after use.

[xiyou.wangcong@gmail.com: remove a useless kfree()]

Signed-off-by: Ignacy Gawędzki &lt;ignacy.gawedzki@green-communications.fr&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.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 1c4cff0cf55011792125b6041bc4e9713e46240f ]

The gnet_stats_copy_app() function gets called, more often than not, with its
second argument a pointer to an automatic variable in the caller's stack.
Therefore, to avoid copying garbage afterwards when calling
gnet_stats_finish_copy(), this data is better copied to a dynamically allocated
memory that gets freed after use.

[xiyou.wangcong@gmail.com: remove a useless kfree()]

Signed-off-by: Ignacy Gawędzki &lt;ignacy.gawedzki@green-communications.fr&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.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>rtnetlink: call -&gt;dellink on failure when -&gt;newlink exists</title>
<updated>2015-03-18T13:10:49+00:00</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-02-13T21:56:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f3b6173e44a8add131deffe49c556472301f281'/>
<id>2f3b6173e44a8add131deffe49c556472301f281</id>
<content type='text'>
[ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ]

Ignacy reported that when eth0 is down and add a vlan device
on top of it like:

  ip link add link eth0 name eth0.1 up type vlan id 1

We will get a refcount leak:

  unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2

The problem is when rtnl_configure_link() fails in rtnl_newlink(),
we simply call unregister_device(), but for stacked device like vlan,
we almost do nothing when we unregister the upper device, more work
is done when we unregister the lower device, so call its -&gt;dellink().

Reported-by: Ignacy Gawedzki &lt;ignacy.gawedzki@green-communications.fr&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.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 7afb8886a05be68e376655539a064ec672de8a8e ]

Ignacy reported that when eth0 is down and add a vlan device
on top of it like:

  ip link add link eth0 name eth0.1 up type vlan id 1

We will get a refcount leak:

  unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2

The problem is when rtnl_configure_link() fails in rtnl_newlink(),
we simply call unregister_device(), but for stacked device like vlan,
we almost do nothing when we unregister the upper device, more work
is done when we unregister the lower device, so call its -&gt;dellink().

Reported-by: Ignacy Gawedzki &lt;ignacy.gawedzki@green-communications.fr&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.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>rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY</title>
<updated>2015-03-18T13:10:48+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2015-02-05T17:44:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f630d422d9a18523c75be7fa81d413210904a44'/>
<id>4f630d422d9a18523c75be7fa81d413210904a44</id>
<content type='text'>
[ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ]

ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].

The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.

The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.

Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
Cc: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Cc: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&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 364d5716a7adb91b731a35765d369602d68d2881 ]

ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].

The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.

The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.

Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
Cc: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Cc: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&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>pktgen: fix UDP checksum computation</title>
<updated>2015-03-18T13:10:48+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2015-02-04T22:08:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18bb5d3023fbf4331128c67df627cd88ab47911b'/>
<id>18bb5d3023fbf4331128c67df627cd88ab47911b</id>
<content type='text'>
[ Upstream commit 7744b5f3693cc06695cb9d6667671c790282730f ]

This patch fixes two issues in UDP checksum computation in pktgen.

First, the pseudo-header uses the source and destination IP
addresses. Currently, the ports are used for IPv4.

Second, the UDP checksum covers both header and data.  So we need to
generate the data earlier (move pktgen_finalize_skb up), and compute
the checksum for UDP header + data.

Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&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 7744b5f3693cc06695cb9d6667671c790282730f ]

This patch fixes two issues in UDP checksum computation in pktgen.

First, the pseudo-header uses the source and destination IP
addresses. Currently, the ports are used for IPv4.

Second, the UDP checksum covers both header and data.  So we need to
generate the data earlier (move pktgen_finalize_skb up), and compute
the checksum for UDP header + data.

Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Acked-by: Thomas Graf &lt;tgraf@suug.ch&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>flowcache: Fix kernel panic in flow_cache_flush_task</title>
<updated>2015-03-18T13:10:48+00:00</updated>
<author>
<name>Miroslav Urbanek</name>
<email>mu@miroslavurbanek.com</email>
</author>
<published>2015-02-05T15:36:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ec37c5e28b90c8f9f5173c0a7a61d513684f7b5'/>
<id>3ec37c5e28b90c8f9f5173c0a7a61d513684f7b5</id>
<content type='text'>
[ Upstream commit 233c96fc077d310772375d47522fb444ff546905 ]

flow_cache_flush_task references a structure member flow_cache_gc_work
where it should reference flow_cache_flush_task instead.

Kernel panic occurs on kernels using IPsec during XFRM garbage
collection. The garbage collection interval can be shortened using the
following sysctl settings:

net.ipv4.xfrm4_gc_thresh=4
net.ipv6.xfrm6_gc_thresh=4

With the default settings, our productions servers crash approximately
once a week. With the settings above, they crash immediately.

Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Tomáš Charvát &lt;tc@excello.cz&gt;
Tested-by: Jan Hejl &lt;jh@excello.cz&gt;
Signed-off-by: Miroslav Urbanek &lt;mu@miroslavurbanek.com&gt;
Acked-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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 233c96fc077d310772375d47522fb444ff546905 ]

flow_cache_flush_task references a structure member flow_cache_gc_work
where it should reference flow_cache_flush_task instead.

Kernel panic occurs on kernels using IPsec during XFRM garbage
collection. The garbage collection interval can be shortened using the
following sysctl settings:

net.ipv4.xfrm4_gc_thresh=4
net.ipv6.xfrm6_gc_thresh=4

With the default settings, our productions servers crash approximately
once a week. With the settings above, they crash immediately.

Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Tomáš Charvát &lt;tc@excello.cz&gt;
Tested-by: Jan Hejl &lt;jh@excello.cz&gt;
Signed-off-by: Miroslav Urbanek &lt;mu@miroslavurbanek.com&gt;
Acked-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;
</pre>
</div>
</content>
</entry>
</feed>
