<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/core, branch v4.4.15</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>bpf: try harder on clones when writing into skb</title>
<updated>2016-07-11T16:31:12+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2016-02-19T22:05:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b30cc5b14fc0981a613969bfa048aa706347d1c3'/>
<id>b30cc5b14fc0981a613969bfa048aa706347d1c3</id>
<content type='text'>
[ Upstream commit 3697649ff29e0f647565eed04b27a7779c646a22 ]

When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().

Reported-by: Ashhad Sheikh &lt;ashhadsheikh394@gmail.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.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 3697649ff29e0f647565eed04b27a7779c646a22 ]

When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().

Reported-by: Ashhad Sheikh &lt;ashhadsheikh394@gmail.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.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>neigh: Explicitly declare RCU-bh read side critical section in neigh_xmit()</title>
<updated>2016-07-11T16:31:12+00:00</updated>
<author>
<name>David Barroso</name>
<email>dbarroso@fastly.com</email>
</author>
<published>2016-06-28T08:16:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f4de1e74580acbc3a2b4cfd7d257e6ad2f8734ec'/>
<id>f4de1e74580acbc3a2b4cfd7d257e6ad2f8734ec</id>
<content type='text'>
[ Upstream commit b560f03ddfb072bca65e9440ff0dc4f9b1d1f056 ]

neigh_xmit() expects to be called inside an RCU-bh read side critical
section, and while one of its two current callers gets this right, the
other one doesn't.

More specifically, neigh_xmit() has two callers, mpls_forward() and
mpls_output(), and while both callers call neigh_xmit() under
rcu_read_lock(), this provides sufficient protection for neigh_xmit()
only in the case of mpls_forward(), as that is always called from
softirq context and therefore doesn't need explicit BH protection,
while mpls_output() can be called from process context with softirqs
enabled.

When mpls_output() is called from process context, with softirqs
enabled, we can be preempted by a softirq at any time, and RCU-bh
considers the completion of a softirq as signaling the end of any
pending read-side critical sections, so if we do get a softirq
while we are in the part of neigh_xmit() that expects to be run inside
an RCU-bh read side critical section, we can end up with an unexpected
RCU grace period running right in the middle of that critical section,
making things go boom.

This patch fixes this impedance mismatch in the callee, by making
neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that
expects to be treated as an RCU-bh read side critical section, as this
seems a safer option than fixing it in the callers.

Fixes: 4fd3d7d9e868f ("neigh: Add helper function neigh_xmit")
Signed-off-by: David Barroso &lt;dbarroso@fastly.com&gt;
Signed-off-by: Lennert Buytenhek &lt;lbuytenhek@fastly.com&gt;
Acked-by: David Ahern &lt;dsa@cumulusnetworks.com&gt;
Acked-by: Robert Shearman &lt;rshearma@brocade.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 b560f03ddfb072bca65e9440ff0dc4f9b1d1f056 ]

neigh_xmit() expects to be called inside an RCU-bh read side critical
section, and while one of its two current callers gets this right, the
other one doesn't.

More specifically, neigh_xmit() has two callers, mpls_forward() and
mpls_output(), and while both callers call neigh_xmit() under
rcu_read_lock(), this provides sufficient protection for neigh_xmit()
only in the case of mpls_forward(), as that is always called from
softirq context and therefore doesn't need explicit BH protection,
while mpls_output() can be called from process context with softirqs
enabled.

When mpls_output() is called from process context, with softirqs
enabled, we can be preempted by a softirq at any time, and RCU-bh
considers the completion of a softirq as signaling the end of any
pending read-side critical sections, so if we do get a softirq
while we are in the part of neigh_xmit() that expects to be run inside
an RCU-bh read side critical section, we can end up with an unexpected
RCU grace period running right in the middle of that critical section,
making things go boom.

This patch fixes this impedance mismatch in the callee, by making
neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that
expects to be treated as an RCU-bh read side critical section, as this
seems a safer option than fixing it in the callers.

Fixes: 4fd3d7d9e868f ("neigh: Add helper function neigh_xmit")
Signed-off-by: David Barroso &lt;dbarroso@fastly.com&gt;
Signed-off-by: Lennert Buytenhek &lt;lbuytenhek@fastly.com&gt;
Acked-by: David Ahern &lt;dsa@cumulusnetworks.com&gt;
Acked-by: Robert Shearman &lt;rshearma@brocade.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: fix infoleak in rtnetlink</title>
<updated>2016-05-19T00:06:41+00:00</updated>
<author>
<name>Kangjie Lu</name>
<email>kangjielu@gmail.com</email>
</author>
<published>2016-05-03T20:46:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0c0313681aaa0c4514c6794635aba82691d2154'/>
<id>e0c0313681aaa0c4514c6794635aba82691d2154</id>
<content type='text'>
[ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]

The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”.

Signed-off-by: Kangjie Lu &lt;kjlu@gatech.edu&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 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]

The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”.

Signed-off-by: Kangjie Lu &lt;kjlu@gatech.edu&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>vlan: pull on __vlan_insert_tag error path and fix csum correction</title>
<updated>2016-05-19T00:06:36+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2016-04-16T00:27:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a66ce519a3e9aca63739da0d716555588df5cc48'/>
<id>a66ce519a3e9aca63739da0d716555588df5cc48</id>
<content type='text'>
[ Upstream commit 9241e2df4fbc648a92ea0752918e05c26255649e ]

When __vlan_insert_tag() fails from skb_vlan_push() path due to the
skb_cow_head(), we need to undo the __skb_push() in the error path
as well that was done earlier to move skb-&gt;data pointer to mac header.

Moreover, I noticed that when in the non-error path the __skb_pull()
is done and the original offset to mac header was non-zero, we fixup
from a wrong skb-&gt;data offset in the checksum complete processing.

So the skb_postpush_rcsum() really needs to be done before __skb_pull()
where skb-&gt;data still points to the mac header start and thus operates
under the same conditions as in __vlan_insert_tag().

Fixes: 93515d53b133 ("net: move vlan pop/push functions into common code")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Jiri Pirko &lt;jiri@mellanox.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 9241e2df4fbc648a92ea0752918e05c26255649e ]

When __vlan_insert_tag() fails from skb_vlan_push() path due to the
skb_cow_head(), we need to undo the __skb_push() in the error path
as well that was done earlier to move skb-&gt;data pointer to mac header.

Moreover, I noticed that when in the non-error path the __skb_pull()
is done and the original offset to mac header was non-zero, we fixup
from a wrong skb-&gt;data offset in the checksum complete processing.

So the skb_postpush_rcsum() really needs to be done before __skb_pull()
where skb-&gt;data still points to the mac header start and thus operates
under the same conditions as in __vlan_insert_tag().

Fixes: 93515d53b133 ("net: move vlan pop/push functions into common code")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Jiri Pirko &lt;jiri@mellanox.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: use skb_postpush_rcsum instead of own implementations</title>
<updated>2016-05-19T00:06:36+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2016-02-19T23:29:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79fdabe8706bd240c083a848f64081a4bc46d7af'/>
<id>79fdabe8706bd240c083a848f64081a4bc46d7af</id>
<content type='text'>
[ Upstream commit 6b83d28a55a891a9d70fc61ccb1c138e47dcbe74 ]

Replace individual implementations with the recently introduced
skb_postpush_rcsum() helper.

Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Tom Herbert &lt;tom@herbertland.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.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 6b83d28a55a891a9d70fc61ccb1c138e47dcbe74 ]

Replace individual implementations with the recently introduced
skb_postpush_rcsum() helper.

Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Tom Herbert &lt;tom@herbertland.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.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>tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter</title>
<updated>2016-04-20T06:42:06+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2016-03-31T00:13:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e137eeb38d2431ded3ec1aff84183258f1dd4162'/>
<id>e137eeb38d2431ded3ec1aff84183258f1dd4162</id>
<content type='text'>
[ Upstream commit 5a5abb1fa3b05dd6aa821525832644c1e7d2905f ]

Sasha Levin reported a suspicious rcu_dereference_protected() warning
found while fuzzing with trinity that is similar to this one:

  [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
  [   52.765688] other info that might help us debug this:
  [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
  [   52.765701] 1 lock held by a.out/1525:
  [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff816a64b7&gt;] rtnl_lock+0x17/0x20
  [   52.765721] stack backtrace:
  [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
  [...]
  [   52.765768] Call Trace:
  [   52.765775]  [&lt;ffffffff813e488d&gt;] dump_stack+0x85/0xc8
  [   52.765784]  [&lt;ffffffff810f2fa5&gt;] lockdep_rcu_suspicious+0xd5/0x110
  [   52.765792]  [&lt;ffffffff816afdc2&gt;] sk_detach_filter+0x82/0x90
  [   52.765801]  [&lt;ffffffffa0883425&gt;] tun_detach_filter+0x35/0x90 [tun]
  [   52.765810]  [&lt;ffffffffa0884ed4&gt;] __tun_chr_ioctl+0x354/0x1130 [tun]
  [   52.765818]  [&lt;ffffffff8136fed0&gt;] ? selinux_file_ioctl+0x130/0x210
  [   52.765827]  [&lt;ffffffffa0885ce3&gt;] tun_chr_ioctl+0x13/0x20 [tun]
  [   52.765834]  [&lt;ffffffff81260ea6&gt;] do_vfs_ioctl+0x96/0x690
  [   52.765843]  [&lt;ffffffff81364af3&gt;] ? security_file_ioctl+0x43/0x60
  [   52.765850]  [&lt;ffffffff81261519&gt;] SyS_ioctl+0x79/0x90
  [   52.765858]  [&lt;ffffffff81003ba2&gt;] do_syscall_64+0x62/0x140
  [   52.765866]  [&lt;ffffffff817d563f&gt;] entry_SYSCALL64_slow_path+0x25/0x25

Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.

Since the fix in f91ff5b9ff52 ("net: sk_{detach|attach}_filter() rcu
fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
filter with rcu_dereference_protected(), checking whether socket lock
is held in control path.

Since its introduction in 994051625981 ("tun: socket filter support"),
tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
sock_owned_by_user(sk) doesn't apply in this specific case and therefore
triggers the false positive.

Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
that is used by tap filters and pass in lockdep_rtnl_is_held() for the
rcu_dereference_protected() checks instead.

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&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 5a5abb1fa3b05dd6aa821525832644c1e7d2905f ]

Sasha Levin reported a suspicious rcu_dereference_protected() warning
found while fuzzing with trinity that is similar to this one:

  [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
  [   52.765688] other info that might help us debug this:
  [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
  [   52.765701] 1 lock held by a.out/1525:
  [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff816a64b7&gt;] rtnl_lock+0x17/0x20
  [   52.765721] stack backtrace:
  [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
  [...]
  [   52.765768] Call Trace:
  [   52.765775]  [&lt;ffffffff813e488d&gt;] dump_stack+0x85/0xc8
  [   52.765784]  [&lt;ffffffff810f2fa5&gt;] lockdep_rcu_suspicious+0xd5/0x110
  [   52.765792]  [&lt;ffffffff816afdc2&gt;] sk_detach_filter+0x82/0x90
  [   52.765801]  [&lt;ffffffffa0883425&gt;] tun_detach_filter+0x35/0x90 [tun]
  [   52.765810]  [&lt;ffffffffa0884ed4&gt;] __tun_chr_ioctl+0x354/0x1130 [tun]
  [   52.765818]  [&lt;ffffffff8136fed0&gt;] ? selinux_file_ioctl+0x130/0x210
  [   52.765827]  [&lt;ffffffffa0885ce3&gt;] tun_chr_ioctl+0x13/0x20 [tun]
  [   52.765834]  [&lt;ffffffff81260ea6&gt;] do_vfs_ioctl+0x96/0x690
  [   52.765843]  [&lt;ffffffff81364af3&gt;] ? security_file_ioctl+0x43/0x60
  [   52.765850]  [&lt;ffffffff81261519&gt;] SyS_ioctl+0x79/0x90
  [   52.765858]  [&lt;ffffffff81003ba2&gt;] do_syscall_64+0x62/0x140
  [   52.765866]  [&lt;ffffffff817d563f&gt;] entry_SYSCALL64_slow_path+0x25/0x25

Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.

Since the fix in f91ff5b9ff52 ("net: sk_{detach|attach}_filter() rcu
fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
filter with rcu_dereference_protected(), checking whether socket lock
is held in control path.

Since its introduction in 994051625981 ("tun: socket filter support"),
tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
sock_owned_by_user(sk) doesn't apply in this specific case and therefore
triggers the false positive.

Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
that is used by tap filters and pass in lockdep_rtnl_is_held() for the
rcu_dereference_protected() checks instead.

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&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>rtnl: fix msg size calculation in if_nlmsg_size()</title>
<updated>2016-04-20T06:42:05+00:00</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2016-03-31T16:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18baf0e01eefd27156d8a8fc5ade1ad8930a1b3d'/>
<id>18baf0e01eefd27156d8a8fc5ade1ad8930a1b3d</id>
<content type='text'>
[ Upstream commit c57c7a95da842807b475b823ed2e5435c42cb3b0 ]

Size of the attribute IFLA_PHYS_PORT_NAME was missing.

Fixes: db24a9044ee1 ("net: add support for phys_port_name")
CC: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: David Ahern &lt;dsahern@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 c57c7a95da842807b475b823ed2e5435c42cb3b0 ]

Size of the attribute IFLA_PHYS_PORT_NAME was missing.

Fixes: db24a9044ee1 ("net: add support for phys_port_name")
CC: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: David Ahern &lt;dsahern@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: fix bridge multicast packet checksum validation</title>
<updated>2016-04-20T06:41:58+00:00</updated>
<author>
<name>Linus Lüssing</name>
<email>linus.luessing@c0d3.blue</email>
</author>
<published>2016-02-24T03:21:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44bc7d1b9777128656310c0c7b47cb952a7c7b2d'/>
<id>44bc7d1b9777128656310c0c7b47cb952a7c7b2d</id>
<content type='text'>
[ Upstream commit 9b368814b336b0a1a479135eb2815edbc00efd3c ]

We need to update the skb-&gt;csum after pulling the skb, otherwise
an unnecessary checksum (re)computation can ocure for IGMP/MLD packets
in the bridge code. Additionally this fixes the following splats for
network devices / bridge ports with support for and enabled RX checksum
offloading:

[...]
[   43.986968] eth0: hw csum failure
[   43.990344] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0 #2
[   43.996193] Hardware name: BCM2709
[   43.999647] [&lt;800204e0&gt;] (unwind_backtrace) from [&lt;8001cf14&gt;] (show_stack+0x10/0x14)
[   44.007432] [&lt;8001cf14&gt;] (show_stack) from [&lt;801ab614&gt;] (dump_stack+0x80/0x90)
[   44.014695] [&lt;801ab614&gt;] (dump_stack) from [&lt;802e4548&gt;] (__skb_checksum_complete+0x6c/0xac)
[   44.023090] [&lt;802e4548&gt;] (__skb_checksum_complete) from [&lt;803a055c&gt;] (ipv6_mc_validate_checksum+0x104/0x178)
[   44.032959] [&lt;803a055c&gt;] (ipv6_mc_validate_checksum) from [&lt;802e111c&gt;] (skb_checksum_trimmed+0x130/0x188)
[   44.042565] [&lt;802e111c&gt;] (skb_checksum_trimmed) from [&lt;803a06e8&gt;] (ipv6_mc_check_mld+0x118/0x338)
[   44.051501] [&lt;803a06e8&gt;] (ipv6_mc_check_mld) from [&lt;803b2c98&gt;] (br_multicast_rcv+0x5dc/0xd00)
[   44.060077] [&lt;803b2c98&gt;] (br_multicast_rcv) from [&lt;803aa510&gt;] (br_handle_frame_finish+0xac/0x51c)
[...]

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&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 9b368814b336b0a1a479135eb2815edbc00efd3c ]

We need to update the skb-&gt;csum after pulling the skb, otherwise
an unnecessary checksum (re)computation can ocure for IGMP/MLD packets
in the bridge code. Additionally this fixes the following splats for
network devices / bridge ports with support for and enabled RX checksum
offloading:

[...]
[   43.986968] eth0: hw csum failure
[   43.990344] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0 #2
[   43.996193] Hardware name: BCM2709
[   43.999647] [&lt;800204e0&gt;] (unwind_backtrace) from [&lt;8001cf14&gt;] (show_stack+0x10/0x14)
[   44.007432] [&lt;8001cf14&gt;] (show_stack) from [&lt;801ab614&gt;] (dump_stack+0x80/0x90)
[   44.014695] [&lt;801ab614&gt;] (dump_stack) from [&lt;802e4548&gt;] (__skb_checksum_complete+0x6c/0xac)
[   44.023090] [&lt;802e4548&gt;] (__skb_checksum_complete) from [&lt;803a055c&gt;] (ipv6_mc_validate_checksum+0x104/0x178)
[   44.032959] [&lt;803a055c&gt;] (ipv6_mc_validate_checksum) from [&lt;802e111c&gt;] (skb_checksum_trimmed+0x130/0x188)
[   44.042565] [&lt;802e111c&gt;] (skb_checksum_trimmed) from [&lt;803a06e8&gt;] (ipv6_mc_check_mld+0x118/0x338)
[   44.051501] [&lt;803a06e8&gt;] (ipv6_mc_check_mld) from [&lt;803b2c98&gt;] (br_multicast_rcv+0x5dc/0xd00)
[   44.060077] [&lt;803b2c98&gt;] (br_multicast_rcv) from [&lt;803aa510&gt;] (br_handle_frame_finish+0xac/0x51c)
[...]

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&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>IFF_NO_QUEUE: Fix for drivers not calling ether_setup()</title>
<updated>2016-03-03T23:07:07+00:00</updated>
<author>
<name>Phil Sutter</name>
<email>phil@nwl.cc</email>
</author>
<published>2016-02-17T14:37:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b87f63bf814c3c8445d3e2baca204a37753fc92'/>
<id>9b87f63bf814c3c8445d3e2baca204a37753fc92</id>
<content type='text'>
[ Upstream commit a813104d923339144078939175faf4e66aca19b4 ]

My implementation around IFF_NO_QUEUE driver flag assumed that leaving
tx_queue_len untouched (specifically: not setting it to zero) by drivers
would make it possible to assign a regular qdisc to them without having
to worry about setting tx_queue_len to a useful value. This was only
partially true: I overlooked that some drivers don't call ether_setup()
and therefore not initialize tx_queue_len to the default value of 1000.
Consequently, removing the workarounds in place for that case in qdisc
implementations which cared about it (namely, pfifo, bfifo, gred, htb,
plug and sfb) leads to problems with these specific interface types and
qdiscs.

Luckily, there's already a sanitization point for drivers setting
tx_queue_len to zero, which can be reused to assign the fallback value
most qdisc implementations used, which is 1.

Fixes: 348e3435cbefa ("net: sched: drop all special handling of tx_queue_len == 0")
Tested-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Phil Sutter &lt;phil@nwl.cc&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 a813104d923339144078939175faf4e66aca19b4 ]

My implementation around IFF_NO_QUEUE driver flag assumed that leaving
tx_queue_len untouched (specifically: not setting it to zero) by drivers
would make it possible to assign a regular qdisc to them without having
to worry about setting tx_queue_len to a useful value. This was only
partially true: I overlooked that some drivers don't call ether_setup()
and therefore not initialize tx_queue_len to the default value of 1000.
Consequently, removing the workarounds in place for that case in qdisc
implementations which cared about it (namely, pfifo, bfifo, gred, htb,
plug and sfb) leads to problems with these specific interface types and
qdiscs.

Luckily, there's already a sanitization point for drivers setting
tx_queue_len to zero, which can be reused to assign the fallback value
most qdisc implementations used, which is 1.

Fixes: 348e3435cbefa ("net: sched: drop all special handling of tx_queue_len == 0")
Tested-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Phil Sutter &lt;phil@nwl.cc&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>flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen</title>
<updated>2016-03-03T23:07:06+00:00</updated>
<author>
<name>Alexander Duyck</name>
<email>aduyck@mirantis.com</email>
</author>
<published>2016-02-09T10:49:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b083b36ce3c91abe5ef7b51393d8af66c19fb594'/>
<id>b083b36ce3c91abe5ef7b51393d8af66c19fb594</id>
<content type='text'>
[ Upstream commit 461547f3158978c180d74484d58e82be9b8e7357 ]

This patch fixes an issue with unaligned accesses when using
eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
The fact is when trying to check the length we don't need to be looking at
the flow label so we can reorder the checks to first check if we are
supposed to gather the flow label and then make the call to actually get
it.

v2:  Updated path so that either STOP_AT_FLOW_LABEL or KEY_FLOW_LABEL can
     cause us to check for the flow label.

Reported-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Signed-off-by: Alexander Duyck &lt;aduyck@mirantis.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 461547f3158978c180d74484d58e82be9b8e7357 ]

This patch fixes an issue with unaligned accesses when using
eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
The fact is when trying to check the length we don't need to be looking at
the flow label so we can reorder the checks to first check if we are
supposed to gather the flow label and then make the call to actually get
it.

v2:  Updated path so that either STOP_AT_FLOW_LABEL or KEY_FLOW_LABEL can
     cause us to check for the flow label.

Reported-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Signed-off-by: Alexander Duyck &lt;aduyck@mirantis.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>
