| Message ID | 20190820005821.2644-1-leonardo@linux.ibm.com |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | David Miller |
| Headers | show |
| Series | [1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot | expand |
Leonardo Bras <leonardo@linux.ibm.com> wrote: > If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up > dealing with a IPv6 package, it causes a kernel panic in > fib6_node_lookup_1(), crashing in bad_page_fault. > > The panic is caused by trying to deference a very low address (0x38 > in ppc64le), due to ipv6.fib6_main_tbl = NULL. > BUG: Kernel NULL pointer dereference at 0x00000038 > > Fix this behavior by dropping IPv6 packages if !ipv6_mod_enabled(). Wouldn't fib_netdev.c have the same problem? If so, might be better to place this test in both nft_fib6_eval_type and nft_fib6_eval.
On Tue, 2019-08-20 at 07:36 +0200, Florian Westphal wrote: > Wouldn't fib_netdev.c have the same problem? Probably, but I haven't hit this issue yet. > If so, might be better to place this test in both > nft_fib6_eval_type and nft_fib6_eval. I think that is possible, and not very hard to do. But in my humble viewpoint, it looks like it's nft_fib_inet_eval() and nft_fib_netdev_eval() have the responsibility to choose a valid protocol or drop the package. I am not sure if it would be a good move to transfer this responsibility to nft_fib6_eval_type() and nft_fib6_eval(), so I would rather add the same test to nft_fib_netdev_eval(). Does it make sense? Thanks for the feedback! Leonardo Bras
On Tue, Aug 20, 2019 at 01:15:58PM -0300, Leonardo Bras wrote: > On Tue, 2019-08-20 at 07:36 +0200, Florian Westphal wrote: > > Wouldn't fib_netdev.c have the same problem? > Probably, but I haven't hit this issue yet. > > > If so, might be better to place this test in both > > nft_fib6_eval_type and nft_fib6_eval. > > I think that is possible, and not very hard to do. > > But in my humble viewpoint, it looks like it's nft_fib_inet_eval() and > nft_fib_netdev_eval() have the responsibility to choose a valid > protocol or drop the package. > I am not sure if it would be a good move to transfer this > responsibility to nft_fib6_eval_type() and nft_fib6_eval(), so I would > rather add the same test to nft_fib_netdev_eval(). > > Does it make sense? Please, update common code to netdev and ip6 extensions as Florian suggests. Thanks.
On Wed, 2019-08-21 at 11:58 +0200, Pablo Neira Ayuso wrote: > On Tue, Aug 20, 2019 at 01:15:58PM -0300, Leonardo Bras wrote: > > On Tue, 2019-08-20 at 07:36 +0200, Florian Westphal wrote: > > > Wouldn't fib_netdev.c have the same problem? > > Probably, but I haven't hit this issue yet. > > > > > If so, might be better to place this test in both > > > nft_fib6_eval_type and nft_fib6_eval. > > > > I think that is possible, and not very hard to do. > > > > But in my humble viewpoint, it looks like it's nft_fib_inet_eval() and > > nft_fib_netdev_eval() have the responsibility to choose a valid > > protocol or drop the package. > > I am not sure if it would be a good move to transfer this > > responsibility to nft_fib6_eval_type() and nft_fib6_eval(), so I would > > rather add the same test to nft_fib_netdev_eval(). > > > > Does it make sense? > > Please, update common code to netdev and ip6 extensions as Florian > suggests. > > Thanks. Ok then, I will send a v2 with that change. Thanks,
Hello Pablo, Florian, I implemented a V2 of this patch with the changes you proposed. Could you please give your feedback on that patch? https://lkml.org/lkml/2019/8/21/527 Thanks! On Wed, 2019-08-21 at 11:58 +0200, Pablo Neira Ayuso wrote: > On Tue, Aug 20, 2019 at 01:15:58PM -0300, Leonardo Bras wrote: > > On Tue, 2019-08-20 at 07:36 +0200, Florian Westphal wrote: > > > Wouldn't fib_netdev.c have the same problem? > > Probably, but I haven't hit this issue yet. > > > > > If so, might be better to place this test in both > > > nft_fib6_eval_type and nft_fib6_eval. > > > > I think that is possible, and not very hard to do. > > > > But in my humble viewpoint, it looks like it's nft_fib_inet_eval() and > > nft_fib_netdev_eval() have the responsibility to choose a valid > > protocol or drop the package. > > I am not sure if it would be a good move to transfer this > > responsibility to nft_fib6_eval_type() and nft_fib6_eval(), so I would > > rather add the same test to nft_fib_netdev_eval(). > > > > Does it make sense? > > Please, update common code to netdev and ip6 extensions as Florian > suggests. > > Thanks.
diff --git a/net/netfilter/nft_fib_inet.c b/net/netfilter/nft_fib_inet.c index 465432e0531b..0017afab3c51 100644 --- a/net/netfilter/nft_fib_inet.c +++ b/net/netfilter/nft_fib_inet.c @@ -2,6 +2,7 @@ #include <linux/kernel.h> #include <linux/init.h> +#include <linux/ipv6.h> #include <linux/module.h> #include <linux/netlink.h> #include <linux/netfilter.h> @@ -28,6 +29,8 @@ static void nft_fib_inet_eval(const struct nft_expr *expr, } break; case NFPROTO_IPV6: + if (!ipv6_mod_enabled()) + break; switch (priv->result) { case NFT_FIB_RESULT_OIF: case NFT_FIB_RESULT_OIFNAME:
If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up dealing with a IPv6 package, it causes a kernel panic in fib6_node_lookup_1(), crashing in bad_page_fault. The panic is caused by trying to deference a very low address (0x38 in ppc64le), due to ipv6.fib6_main_tbl = NULL. BUG: Kernel NULL pointer dereference at 0x00000038 Fix this behavior by dropping IPv6 packages if !ipv6_mod_enabled(). Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com> --- net/netfilter/nft_fib_inet.c | 3 +++ 1 file changed, 3 insertions(+)