<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/netfilter, branch v3.14.13</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<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>
<entry>
<title>netfilter: nf_tables: set names cannot be larger than 15 bytes</title>
<updated>2014-05-31T20:20:28+00:00</updated>
<author>
<name>Pablo Neira Ayuso</name>
<email>pablo@netfilter.org</email>
</author>
<published>2014-03-24T14:10:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4d43406bd06f92ab86c31027a2c313b36dc4ba39'/>
<id>4d43406bd06f92ab86c31027a2c313b36dc4ba39</id>
<content type='text'>
commit a9bdd8365684810e3de804f8c51e52c26a5eccbb upstream.

Currently, nf_tables trims off the set name if it exceeeds 15
bytes, so explicitly reject set names that are too large.

Reported-by: Giuseppe Longo &lt;giuseppelng@gmail.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 a9bdd8365684810e3de804f8c51e52c26a5eccbb upstream.

Currently, nf_tables trims off the set name if it exceeeds 15
bytes, so explicitly reject set names that are too large.

Reported-by: Giuseppe Longo &lt;giuseppelng@gmail.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>netfilter: nf_tables: fix nft_cmp_fast failure on big endian for size &lt; 4</title>
<updated>2014-05-31T20:20:27+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2014-04-12T11:17:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d6421db1dbd6a0c6fd6626c6c59d29204db76434'/>
<id>d6421db1dbd6a0c6fd6626c6c59d29204db76434</id>
<content type='text'>
commit b855d416dc17061ebb271ea7ef1201d100531770 upstream.

nft_cmp_fast is used for equality comparisions of size &lt;= 4. For
comparisions of size &lt; 4 byte a mask is calculated that is applied to
both the data from userspace (during initialization) and the register
value (during runtime). Both values are stored using (in effect) memcpy
to a memory area that is then interpreted as u32 by nft_cmp_fast.

This works fine on little endian since smaller types have the same base
address, however on big endian this is not true and the smaller types
are interpreted as a big number with trailing zero bytes.

The mask therefore must not include the lower bytes, but the higher bytes
on big endian. Add a helper function that does a cpu_to_le32 to switch
the bytes on big endian. Since we're dealing with a mask of just consequitive
bits, this works out fine.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&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 b855d416dc17061ebb271ea7ef1201d100531770 upstream.

nft_cmp_fast is used for equality comparisions of size &lt;= 4. For
comparisions of size &lt; 4 byte a mask is calculated that is applied to
both the data from userspace (during initialization) and the register
value (during runtime). Both values are stored using (in effect) memcpy
to a memory area that is then interpreted as u32 by nft_cmp_fast.

This works fine on little endian since smaller types have the same base
address, however on big endian this is not true and the smaller types
are interpreted as a big number with trailing zero bytes.

The mask therefore must not include the lower bytes, but the higher bytes
on big endian. Add a helper function that does a cpu_to_le32 to switch
the bytes on big endian. Since we're dealing with a mask of just consequitive
bits, this works out fine.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&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>core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors</title>
<updated>2014-03-27T19:29:38+00:00</updated>
<author>
<name>Zoltan Kiss</name>
<email>zoltan.kiss@citrix.com</email>
</author>
<published>2014-03-26T22:37:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=36d5fe6a000790f56039afe26834265db0a3ad4c'/>
<id>36d5fe6a000790f56039afe26834265db0a3ad4c</id>
<content type='text'>
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb.

Signed-off-by: Zoltan Kiss &lt;zoltan.kiss@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb.

Signed-off-by: Zoltan Kiss &lt;zoltan.kiss@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: ctnetlink: force null nat binding on insert</title>
<updated>2014-02-17T23:13:51+00:00</updated>
<author>
<name>Pablo Neira Ayuso</name>
<email>pablo@netfilter.org</email>
</author>
<published>2014-02-16T11:15:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0eba801b64cc8284d9024c7ece30415a2b981a72'/>
<id>0eba801b64cc8284d9024c7ece30415a2b981a72</id>
<content type='text'>
Quoting Andrey Vagin:
  When a conntrack is created  by kernel, it is initialized (sets
  IPS_{DST,SRC}_NAT_DONE_BIT bits in nf_nat_setup_info) and only then it
  is added in hashes (__nf_conntrack_hash_insert), so one conntract
  can't be initialized from a few threads concurrently.

  ctnetlink can add an uninitialized conntrack (w/o
  IPS_{DST,SRC}_NAT_DONE_BIT) in hashes, then a few threads can look up
  this conntrack and start initialize it concurrently. It's dangerous,
  because BUG can be triggered from nf_nat_setup_info.

Fix this race by always setting up nat, even if no CTA_NAT_ attribute
was requested before inserting the ct into the hash table. In absence
of CTA_NAT_ attribute, a null binding is created.

This alters current behaviour: Before this patch, the first packet
matching the newly injected conntrack would be run through the nat
table since nf_nat_initialized() returns false.  IOW, this forces
ctnetlink users to specify the desired nat transformation on ct
creation time.

Thanks for Florian Westphal, this patch is based on his original
patch to address this problem, including this patch description.

Reported-By: Andrey Vagin &lt;avagin@gmail.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Quoting Andrey Vagin:
  When a conntrack is created  by kernel, it is initialized (sets
  IPS_{DST,SRC}_NAT_DONE_BIT bits in nf_nat_setup_info) and only then it
  is added in hashes (__nf_conntrack_hash_insert), so one conntract
  can't be initialized from a few threads concurrently.

  ctnetlink can add an uninitialized conntrack (w/o
  IPS_{DST,SRC}_NAT_DONE_BIT) in hashes, then a few threads can look up
  this conntrack and start initialize it concurrently. It's dangerous,
  because BUG can be triggered from nf_nat_setup_info.

Fix this race by always setting up nat, even if no CTA_NAT_ attribute
was requested before inserting the ct into the hash table. In absence
of CTA_NAT_ attribute, a null binding is created.

This alters current behaviour: Before this patch, the first packet
matching the newly injected conntrack would be run through the nat
table since nf_nat_initialized() returns false.  IOW, this forces
ctnetlink users to specify the desired nat transformation on ct
creation time.

Thanks for Florian Westphal, this patch is based on his original
patch to address this problem, including this patch description.

Reported-By: Andrey Vagin &lt;avagin@gmail.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: nf_tables: check if payload length is a power of 2</title>
<updated>2014-02-17T10:21:17+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@redhat.com</email>
</author>
<published>2014-02-16T13:01:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f627ed91d85ed7a189ec8b3b045a0d831e1655e2'/>
<id>f627ed91d85ed7a189ec8b3b045a0d831e1655e2</id>
<content type='text'>
Add a check if payload's length is a power of 2 when selecting ops.
The fast ops were meant for well aligned loads, also this fixes a
small bug when using a length of 3 with some offsets which causes
only 1 byte to be loaded because the fast ops are chosen.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Acked-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a check if payload's length is a power of 2 when selecting ops.
The fast ops were meant for well aligned loads, also this fixes a
small bug when using a length of 3 with some offsets which causes
only 1 byte to be loaded because the fast ops are chosen.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Acked-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: nft_meta: fix typo "CONFIG_NET_CLS_ROUTE"</title>
<updated>2014-02-14T10:37:34+00:00</updated>
<author>
<name>Paul Bolle</name>
<email>pebolle@tiscali.nl</email>
</author>
<published>2014-02-12T09:53:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=06efbd6d5694b2e3cde176f724ba572d57709616'/>
<id>06efbd6d5694b2e3cde176f724ba572d57709616</id>
<content type='text'>
There are two checks for CONFIG_NET_CLS_ROUTE, but the corresponding
Kconfig symbol was dropped in v2.6.39. Since the code guards access to
dst_entry.tclassid it seems CONFIG_IP_ROUTE_CLASSID should be used
instead.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are two checks for CONFIG_NET_CLS_ROUTE, but the corresponding
Kconfig symbol was dropped in v2.6.39. Since the code guards access to
dst_entry.tclassid it seems CONFIG_IP_ROUTE_CLASSID should be used
instead.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
