<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/netfilter, branch v3.14.23</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ipvs: fix ipv6 hook registration for local replies</title>
<updated>2014-10-05T21:52:23+00:00</updated>
<author>
<name>Julian Anastasov</name>
<email>ja@ssi.bg</email>
</author>
<published>2014-08-22T14:53:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9321e2ecf40ab73eb3f74183d8f7a521d8b7eb52'/>
<id>9321e2ecf40ab73eb3f74183d8f7a521d8b7eb52</id>
<content type='text'>
commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream.

commit fc604767613b6d2036cdc35b660bc39451040a47
("ipvs: changes for local real server") from 2.6.37
introduced DNAT support to local real server but the
IPv6 LOCAL_OUT handler ip_vs_local_reply6() is
registered incorrectly as IPv4 hook causing any outgoing
IPv4 traffic to be dropped depending on the IP header values.

Chris tracked down the problem to CONFIG_IP_VS_IPV6=y
Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768

Reported-by: Chris J Arges &lt;chris.j.arges@canonical.com&gt;
Tested-by: Chris J Arges &lt;chris.j.arges@canonical.com&gt;
Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&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>
commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream.

commit fc604767613b6d2036cdc35b660bc39451040a47
("ipvs: changes for local real server") from 2.6.37
introduced DNAT support to local real server but the
IPv6 LOCAL_OUT handler ip_vs_local_reply6() is
registered incorrectly as IPv4 hook causing any outgoing
IPv4 traffic to be dropped depending on the IP header values.

Chris tracked down the problem to CONFIG_IP_VS_IPV6=y
Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768

Reported-by: Chris J Arges &lt;chris.j.arges@canonical.com&gt;
Tested-by: Chris J Arges &lt;chris.j.arges@canonical.com&gt;
Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: x_tables: allow to use default cgroup match</title>
<updated>2014-10-05T21:52:23+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-08-18T13:46:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fcfebe9bc6c789eba97c06e125f23b3f9e261efa'/>
<id>fcfebe9bc6c789eba97c06e125f23b3f9e261efa</id>
<content type='text'>
commit caa8ad94edf686d02b555c65a6162c0d1b434958 upstream.

There's actually no good reason why we cannot use cgroup id 0,
so lets just remove this artificial barrier.

Reported-by: Alexey Perevalov &lt;a.perevalov@samsung.com&gt;
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Tested-by: Alexey Perevalov &lt;a.perevalov@samsung.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&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>
commit caa8ad94edf686d02b555c65a6162c0d1b434958 upstream.

There's actually no good reason why we cannot use cgroup id 0,
so lets just remove this artificial barrier.

Reported-by: Alexey Perevalov &lt;a.perevalov@samsung.com&gt;
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Tested-by: Alexey Perevalov &lt;a.perevalov@samsung.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding</title>
<updated>2014-10-05T21:52:23+00:00</updated>
<author>
<name>Alex Gartrell</name>
<email>agartrell@fb.com</email>
</author>
<published>2014-07-16T22:57:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e19c985650c94578655f47cb6d856767c23b3433'/>
<id>e19c985650c94578655f47cb6d856767c23b3433</id>
<content type='text'>
commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream.

Previously, only the four high bits of the tclass were maintained in the
ipv6 case.  This matches the behavior of ipv4, though whether or not we
should reflect ECN bits may be up for debate.

Signed-off-by: Alex Gartrell &lt;agartrell@fb.com&gt;
Acked-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&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>
commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream.

Previously, only the four high bits of the tclass were maintained in the
ipv6 case.  This matches the behavior of ipv4, though whether or not we
should reflect ECN bits may be up for debate.

Signed-off-by: Alex Gartrell &lt;agartrell@fb.com&gt;
Acked-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: xt_hashlimit: perform garbage collection from process context</title>
<updated>2014-10-05T21:52:23+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-07-24T04:36:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6598554879509476a47929be742b858b3a42372a'/>
<id>6598554879509476a47929be742b858b3a42372a</id>
<content type='text'>
commit 7bd8490eef9776ced7632345df5133384b6be0fe upstream.

xt_hashlimit cannot be used with large hash tables, because garbage
collector is run from a timer. If table is really big, its possible
to hold cpu for more than 500 msec, which is unacceptable.

Switch to a work queue, and use proper scheduling points to remove
latencies spikes.

Later, we also could switch to a smoother garbage collection done
at lookup time, one bucket at a time...

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Reviewed-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&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>
commit 7bd8490eef9776ced7632345df5133384b6be0fe upstream.

xt_hashlimit cannot be used with large hash tables, because garbage
collector is run from a timer. If table is really big, its possible
to hold cpu for more than 500 msec, which is unacceptable.

Switch to a work queue, and use proper scheduling points to remove
latencies spikes.

Later, we also could switch to a smoother garbage collection done
at lookup time, one bucket at a time...

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Reviewed-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipvs: avoid netns exit crash on ip_vs_conn_drop_conntrack</title>
<updated>2014-10-05T21:52:23+00:00</updated>
<author>
<name>Julian Anastasov</name>
<email>ja@ssi.bg</email>
</author>
<published>2014-07-10T06:24:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fd29286dc5c7fa0f135ce30ca59c8c4130c87601'/>
<id>fd29286dc5c7fa0f135ce30ca59c8c4130c87601</id>
<content type='text'>
commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream.

commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack")
added second ip_vs_conn_drop_conntrack call instead of just adding
the needed check. As result, the first call still can cause
crash on netns exit. Remove it.

Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Hans Schillstrom &lt;hans@schillstrom.com&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&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>
commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream.

commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack")
added second ip_vs_conn_drop_conntrack call instead of just adding
the needed check. As result, the first call still can cause
crash on netns exit. Remove it.

Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Hans Schillstrom &lt;hans@schillstrom.com&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>inetpeer: get rid of ip_id_count</title>
<updated>2014-08-14T01:38:23+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-06-02T12:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=265459c3d15b39826d09b3380eef7572fb7649a2'/>
<id>265459c3d15b39826d09b3380eef7572fb7649a2</id>
<content type='text'>
[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: nf_nat: fix oops on netns removal</title>
<updated>2014-07-09T18:18:28+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2014-06-07T19:17:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=82b8759a69e9b0b795e897ec312599953a6c3946'/>
<id>82b8759a69e9b0b795e897ec312599953a6c3946</id>
<content type='text'>
commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f upstream.

Quoting Samu Kallio:

 Basically what's happening is, during netns cleanup,
 nf_nat_net_exit gets called before ipv4_net_exit. As I understand
 it, nf_nat_net_exit is supposed to kill any conntrack entries which
 have NAT context (through nf_ct_iterate_cleanup), but for some
 reason this doesn't happen (perhaps something else is still holding
 refs to those entries?).

 When ipv4_net_exit is called, conntrack entries (including those
 with NAT context) are cleaned up, but the
 nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The
 bug happens when attempting to free a conntrack entry whose NAT hash
 'prev' field points to a slot in the freed hash table (head for that
 bin).

We ignore conntracks with null nat bindings.  But this is wrong,
as these are in bysource hash table as well.

Restore nat-cleaning for the netns-is-being-removed case.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=65191

Fixes: c2d421e1718 ('netfilter: nf_nat: fix race when unloading protocol modules')
Reported-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Debugged-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Tested-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&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>
commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f upstream.

Quoting Samu Kallio:

 Basically what's happening is, during netns cleanup,
 nf_nat_net_exit gets called before ipv4_net_exit. As I understand
 it, nf_nat_net_exit is supposed to kill any conntrack entries which
 have NAT context (through nf_ct_iterate_cleanup), but for some
 reason this doesn't happen (perhaps something else is still holding
 refs to those entries?).

 When ipv4_net_exit is called, conntrack entries (including those
 with NAT context) are cleaned up, but the
 nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The
 bug happens when attempting to free a conntrack entry whose NAT hash
 'prev' field points to a slot in the freed hash table (head for that
 bin).

We ignore conntracks with null nat bindings.  But this is wrong,
as these are in bysource hash table as well.

Restore nat-cleaning for the netns-is-being-removed case.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=65191

Fixes: c2d421e1718 ('netfilter: nf_nat: fix race when unloading protocol modules')
Reported-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Debugged-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Tested-by: Samu Kallio &lt;samu.kallio@aberdeencloud.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipvs: Fix panic due to non-linear skb</title>
<updated>2014-07-07T01:57:29+00:00</updated>
<author>
<name>Peter Christensen</name>
<email>pch@ordbogen.com</email>
</author>
<published>2014-05-24T19:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e3a88572409bfca472be3e0d87f4750478070119'/>
<id>e3a88572409bfca472be3e0d87f4750478070119</id>
<content type='text'>
commit f44a5f45f544561302e855e7bd104e5f506ec01b upstream.

Receiving a ICMP response to an IPIP packet in a non-linear skb could
cause a kernel panic in __skb_pull.

The problem was introduced in
commit f2edb9f7706dcb2c0d9a362b2ba849efe3a97f5e ("ipvs: implement
passive PMTUD for IPIP packets").

Signed-off-by: Peter Christensen &lt;pch@ordbogen.com&gt;
Acked-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&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>
commit f44a5f45f544561302e855e7bd104e5f506ec01b upstream.

Receiving a ICMP response to an IPIP packet in a non-linear skb could
cause a kernel panic in __skb_pull.

The problem was introduced in
commit f2edb9f7706dcb2c0d9a362b2ba849efe3a97f5e ("ipvs: implement
passive PMTUD for IPIP packets").

Signed-off-by: Peter Christensen &lt;pch@ordbogen.com&gt;
Acked-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net: Use netlink_ns_capable to verify the permisions of netlink messages</title>
<updated>2014-06-26T19:15:38+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-04-23T21:29:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=be0ef855baab7248d0fc71cdf78a47fcfd3708f1'/>
<id>be0ef855baab7248d0fc71cdf78a47fcfd3708f1</id>
<content type='text'>
[ Upstream commit 90f62cf30a78721641e08737bda787552428061e ]

It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.

To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.

Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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 90f62cf30a78721641e08737bda787552428061e ]

It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.

To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.

Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>netfilter: nfnetlink: Fix use after free when it fails to process batch</title>
<updated>2014-06-11T18:54:14+00:00</updated>
<author>
<name>Denys Fedoryshchenko</name>
<email>nuclearcat@nuclearcat.com</email>
</author>
<published>2014-05-04T11:35:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07e8687141e5073ff7931666982232bdc4bc3400'/>
<id>07e8687141e5073ff7931666982232bdc4bc3400</id>
<content type='text'>
commit ecd15dd7e45f3683fa8142b9f2c015dfaa0c243d upstream.

This bug manifests when calling the nft command line tool without
nf_tables kernel support.

kernel message:
[   44.071555] Netfilter messages via NETLINK v0.30.
[   44.072253] BUG: unable to handle kernel NULL pointer dereference at 0000000000000119
[   44.072264] IP: [&lt;ffffffff8171db1f&gt;] netlink_getsockbyportid+0xf/0x70
[   44.072272] PGD 7f2b74067 PUD 7f2b73067 PMD 0
[   44.072277] Oops: 0000 [#1] SMP
[...]
[   44.072369] Call Trace:
[   44.072373]  [&lt;ffffffff8171fd81&gt;] netlink_unicast+0x91/0x200
[   44.072377]  [&lt;ffffffff817206c9&gt;] netlink_ack+0x99/0x110
[   44.072381]  [&lt;ffffffffa004b951&gt;] nfnetlink_rcv+0x3c1/0x408 [nfnetlink]
[   44.072385]  [&lt;ffffffff8171fde3&gt;] netlink_unicast+0xf3/0x200
[   44.072389]  [&lt;ffffffff817201ef&gt;] netlink_sendmsg+0x2ff/0x740
[   44.072394]  [&lt;ffffffff81044752&gt;] ? __mmdrop+0x62/0x90
[   44.072398]  [&lt;ffffffff816dafdb&gt;] sock_sendmsg+0x8b/0xc0
[   44.072403]  [&lt;ffffffff812f1af5&gt;] ? copy_user_enhanced_fast_string+0x5/0x10
[   44.072406]  [&lt;ffffffff816dbb6c&gt;] ? move_addr_to_kernel+0x2c/0x50
[   44.072410]  [&lt;ffffffff816db423&gt;] ___sys_sendmsg+0x3c3/0x3d0
[   44.072415]  [&lt;ffffffff811301ba&gt;] ? handle_mm_fault+0xa9a/0xc60
[   44.072420]  [&lt;ffffffff811362d6&gt;] ? mmap_region+0x166/0x5a0
[   44.072424]  [&lt;ffffffff817da84c&gt;] ? __do_page_fault+0x1dc/0x510
[   44.072428]  [&lt;ffffffff812b8b2c&gt;] ? apparmor_capable+0x1c/0x60
[   44.072435]  [&lt;ffffffff817d6e9a&gt;] ? _raw_spin_unlock_bh+0x1a/0x20
[   44.072439]  [&lt;ffffffff816dfc86&gt;] ? release_sock+0x106/0x150
[   44.072443]  [&lt;ffffffff816dc212&gt;] __sys_sendmsg+0x42/0x80
[   44.072446]  [&lt;ffffffff816dc262&gt;] SyS_sendmsg+0x12/0x20
[   44.072450]  [&lt;ffffffff817df616&gt;] system_call_fastpath+0x1a/0x1f

Signed-off-by: Denys Fedoryshchenko &lt;nuclearcat@nuclearcat.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&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>
commit ecd15dd7e45f3683fa8142b9f2c015dfaa0c243d upstream.

This bug manifests when calling the nft command line tool without
nf_tables kernel support.

kernel message:
[   44.071555] Netfilter messages via NETLINK v0.30.
[   44.072253] BUG: unable to handle kernel NULL pointer dereference at 0000000000000119
[   44.072264] IP: [&lt;ffffffff8171db1f&gt;] netlink_getsockbyportid+0xf/0x70
[   44.072272] PGD 7f2b74067 PUD 7f2b73067 PMD 0
[   44.072277] Oops: 0000 [#1] SMP
[...]
[   44.072369] Call Trace:
[   44.072373]  [&lt;ffffffff8171fd81&gt;] netlink_unicast+0x91/0x200
[   44.072377]  [&lt;ffffffff817206c9&gt;] netlink_ack+0x99/0x110
[   44.072381]  [&lt;ffffffffa004b951&gt;] nfnetlink_rcv+0x3c1/0x408 [nfnetlink]
[   44.072385]  [&lt;ffffffff8171fde3&gt;] netlink_unicast+0xf3/0x200
[   44.072389]  [&lt;ffffffff817201ef&gt;] netlink_sendmsg+0x2ff/0x740
[   44.072394]  [&lt;ffffffff81044752&gt;] ? __mmdrop+0x62/0x90
[   44.072398]  [&lt;ffffffff816dafdb&gt;] sock_sendmsg+0x8b/0xc0
[   44.072403]  [&lt;ffffffff812f1af5&gt;] ? copy_user_enhanced_fast_string+0x5/0x10
[   44.072406]  [&lt;ffffffff816dbb6c&gt;] ? move_addr_to_kernel+0x2c/0x50
[   44.072410]  [&lt;ffffffff816db423&gt;] ___sys_sendmsg+0x3c3/0x3d0
[   44.072415]  [&lt;ffffffff811301ba&gt;] ? handle_mm_fault+0xa9a/0xc60
[   44.072420]  [&lt;ffffffff811362d6&gt;] ? mmap_region+0x166/0x5a0
[   44.072424]  [&lt;ffffffff817da84c&gt;] ? __do_page_fault+0x1dc/0x510
[   44.072428]  [&lt;ffffffff812b8b2c&gt;] ? apparmor_capable+0x1c/0x60
[   44.072435]  [&lt;ffffffff817d6e9a&gt;] ? _raw_spin_unlock_bh+0x1a/0x20
[   44.072439]  [&lt;ffffffff816dfc86&gt;] ? release_sock+0x106/0x150
[   44.072443]  [&lt;ffffffff816dc212&gt;] __sys_sendmsg+0x42/0x80
[   44.072446]  [&lt;ffffffff816dc262&gt;] SyS_sendmsg+0x12/0x20
[   44.072450]  [&lt;ffffffff817df616&gt;] system_call_fastpath+0x1a/0x1f

Signed-off-by: Denys Fedoryshchenko &lt;nuclearcat@nuclearcat.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
