netfilter stable requests for 4.14, 4.16

netfilter stable requests for 4.14, 4.16

[Florian Westphal]

Hello,

Here is a list of netfilter bug fixes that I'd like to
see in 4.16 and 4.14.

I've cherry-picked these and with one exception (noted
below) all pick cleanly. Patches are listed in top-down order.

For v4.16.y and v4.14.y:

b8e9dc1c75714ceb53615743e1036f76e00f5a17
("netfilter: nf_tables: nft_compat: fix refcount leak on xt module")

8bdf164744b2c7f63561846c01cff3db597f282d
("netfilter: nft_compat: prepare for indirect info storage")

Necessary to make the fix (next patch below) apply.

732a8049f365f514d0607e03938491bf6cb0d620
("netfilter: nft_compat: fix handling of large matchinfo size")

Without it, some iptables -A will fail when using iptables via
nfnetlink (notably the cgroup match).

009240940e84c1c089af88b454f7e804a4c5bd1b
("netfilter: nf_tables: don't assume chain stats are set when jumplabel is set")

Fixes null-ptr deref.

bb7b40aecbf778c0c83a5bd62b0f03ca9f49a618
("netfilter: nf_tables: bogus EBUSY in chain deletions")

Fixes erroneous reject of some valid rulesets.

97a0549b15a0b466c47f6a0143a490a082c64b4e
("netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval")

This fixes a bug where 'nft ... meta nftrace set 0' may set a nonzero
value instead.

ad9d9e85072b668731f356be0a3750a3ba22a607
("netfilter: nf_tables: disable preemption in nft_update_chain_stats()")

360cc79d9d299ce297b205508276285ceffc5fa8
("netfilter: nf_tables: fix NULL-ptr in nf_tables_dump_obj()"), bug added in v4.14-rc1

Applies cleanly to 4.16 but in 4.14 tjis fails as the 2nd location that
is patched (nf_tables_dump_flowtable) doesn't exist.  So in 4.14 this is
a one-line change:
   -    if (filter && filter->table[0] &&
   +    if (filter && filter->table &&

bbb8c61f97e3a2dd91b30d3e57b7964a67569d11
("netfilter: nf_tables: increase nft_counters_enabled in nft_chain_stats_replace()"

This fixes underflow of the static_key used for the base chain counters.

f0dfd7a2b35b02030949100247d851b793cb275f
("netfilter: nf_tables: fix memory leak on error exit return"), since 4.12

additional change for v4.14.y (its already in 4.16):

467697d289e7e6e1b15910d99096c0da08c56d5b
("netfilter: nf_tables: add missing netlink attrs to policies")

If you'd like me to handle such larger requests differently please
let me know your preferenced way to handle this.

Thanks,
Florian

Re: netfilter stable requests for 4.14, 4.16

[Greg KH]

On Wed, Jun 27, 2018 at 11:35:15AM +0200, Florian Westphal wrote:
> Hello,
> 
> Here is a list of netfilter bug fixes that I'd like to
> see in 4.16 and 4.14.
> 
> I've cherry-picked these and with one exception (noted
> below) all pick cleanly. Patches are listed in top-down order.
> 
> For v4.16.y and v4.14.y:
> 
> b8e9dc1c75714ceb53615743e1036f76e00f5a17
> ("netfilter: nf_tables: nft_compat: fix refcount leak on xt module")
> 
> 8bdf164744b2c7f63561846c01cff3db597f282d
> ("netfilter: nft_compat: prepare for indirect info storage")
> 
> Necessary to make the fix (next patch below) apply.
> 
> 732a8049f365f514d0607e03938491bf6cb0d620
> ("netfilter: nft_compat: fix handling of large matchinfo size")
> 
> Without it, some iptables -A will fail when using iptables via
> nfnetlink (notably the cgroup match).
> 
> 009240940e84c1c089af88b454f7e804a4c5bd1b
> ("netfilter: nf_tables: don't assume chain stats are set when jumplabel is set")
> 
> Fixes null-ptr deref.
> 
> bb7b40aecbf778c0c83a5bd62b0f03ca9f49a618
> ("netfilter: nf_tables: bogus EBUSY in chain deletions")
> 
> Fixes erroneous reject of some valid rulesets.
> 
> 97a0549b15a0b466c47f6a0143a490a082c64b4e
> ("netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval")
> 
> This fixes a bug where 'nft ... meta nftrace set 0' may set a nonzero
> value instead.
> 
> ad9d9e85072b668731f356be0a3750a3ba22a607
> ("netfilter: nf_tables: disable preemption in nft_update_chain_stats()")
> 
> 360cc79d9d299ce297b205508276285ceffc5fa8
> ("netfilter: nf_tables: fix NULL-ptr in nf_tables_dump_obj()"), bug added in v4.14-rc1
> 
> Applies cleanly to 4.16 but in 4.14 tjis fails as the 2nd location that
> is patched (nf_tables_dump_flowtable) doesn't exist.  So in 4.14 this is
> a one-line change:
>    -    if (filter && filter->table[0] &&
>    +    if (filter && filter->table &&

I don't understand this, can you provide a backported patch for 4.14.y?

> bbb8c61f97e3a2dd91b30d3e57b7964a67569d11
> ("netfilter: nf_tables: increase nft_counters_enabled in nft_chain_stats_replace()"
> 
> This fixes underflow of the static_key used for the base chain counters.
> 
> f0dfd7a2b35b02030949100247d851b793cb275f
> ("netfilter: nf_tables: fix memory leak on error exit return"), since 4.12
> 
> additional change for v4.14.y (its already in 4.16):
> 
> 467697d289e7e6e1b15910d99096c0da08c56d5b
> ("netfilter: nf_tables: add missing netlink attrs to policies")
> 
> If you'd like me to handle such larger requests differently please
> let me know your preferenced way to handle this.

This was fine, all but the one patch above applied to 4.14 now.  4.16 is
end-of-life a week or so ago, sorry.

greg k-h

Re: netfilter stable requests for 4.14, 4.16

[Florian Westphal]

Greg KH <greg@kroah.com> wrote:
> > 360cc79d9d299ce297b205508276285ceffc5fa8
> > ("netfilter: nf_tables: fix NULL-ptr in nf_tables_dump_obj()"), bug added in v4.14-rc1
> > 
> > Applies cleanly to 4.16 but in 4.14 tjis fails as the 2nd location that
> > is patched (nf_tables_dump_flowtable) doesn't exist.  So in 4.14 this is
> > a one-line change:
> >    -    if (filter && filter->table[0] &&
> >    +    if (filter && filter->table &&
> 
> I don't understand this, can you provide a backported patch for 4.14.y?

Sure, coming in a few seconds.
Addmittingly, poorly worded on my side and git conflict resolution
looks very nasty...

> > If you'd like me to handle such larger requests differently please
> > let me know your preferenced way to handle this.
> 
> This was fine, all but the one patch above applied to 4.14 now.  4.16 is
> end-of-life a week or so ago, sorry.

No problem, 4.16.y users can move to 4.17.y and will get fixes this way
then.