Re: [PATCH net] netfilter: nat: cope with negative port range
On Tue, 2018-02-13 at 18:02 +0100, Florian Westphal wrote: > Paolo Abeni wrote: > > Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core") > > are you sure? > When I looked this was a day 0 bug, the code was just moved from ipv4. You are right, the named commit just move around the bugged code, the bug is apparently there since: commit 5b1158e909ecbe1a052203e0d8df15633f829930 Author: Jozsef Kadlecsik Date: Sat Dec 2 22:07:13 2006 -0800 [NETFILTER]: Add NAT support for nf_conntrack I'll send a v2 with an updated commit message, thanks! Paolo -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] netfilter: nat: cope with negative port range
Paolo Abeni wrote: > Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core") are you sure? When I looked this was a day 0 bug, the code was just moved from ipv4. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] netfilter: nat: cope with negative port range
syzbot reported a division by 0 bug in the netfilter nat code: divide error: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 4168 Comm: syzkaller034710 Not tainted 4.16.0-rc1+ #309 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:nf_nat_l4proto_unique_tuple+0x291/0x530 net/netfilter/nf_nat_proto_common.c:88 RSP: 0018:8801b2466778 EFLAGS: 00010246 RAX: f153 RBX: 8801b2466dd8 RCX: 8801b2466c7c RDX: RSI: 8801b2466c58 RDI: 8801db5293ac RBP: 8801b24667d8 R08: 8801b8ba6dc0 R09: 88af5900 R10: 8801b24666f0 R11: R12: 2990f153 R13: 0001 R14: R15: 8801b2466c7c FS: 017e3880() GS:8801db50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 208fdfe4 CR3: 0001b5340002 CR4: 001606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: dccp_unique_tuple+0x40/0x50 net/netfilter/nf_nat_proto_dccp.c:30 get_unique_tuple+0xc28/0x1c10 net/netfilter/nf_nat_core.c:362 nf_nat_setup_info+0x1c2/0xe00 net/netfilter/nf_nat_core.c:406 nf_nat_redirect_ipv6+0x306/0x730 net/netfilter/nf_nat_redirect.c:124 redirect_tg6+0x7f/0xb0 net/netfilter/xt_REDIRECT.c:34 ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365 ip6table_nat_do_chain+0x65/0x80 net/ipv6/netfilter/ip6table_nat.c:41 nf_nat_ipv6_fn+0x594/0xa80 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:302 nf_nat_ipv6_local_fn+0x33/0x5d0 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:407 ip6table_nat_local_fn+0x2c/0x40 net/ipv6/netfilter/ip6table_nat.c:69 nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline] nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483 nf_hook include/linux/netfilter.h:243 [inline] NF_HOOK include/linux/netfilter.h:286 [inline] ip6_xmit+0x10ec/0x2260 net/ipv6/ip6_output.c:277 inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139 dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142 dccp_connect+0x369/0x670 net/dccp/output.c:564 dccp_v6_connect+0xe17/0x1bf0 net/dccp/ipv6.c:946 __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620 inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:684 SYSC_connect+0x213/0x4a0 net/socket.c:1639 SyS_connect+0x24/0x30 net/socket.c:1620 do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x26/0x9b RIP: 0033:0x441c69 RSP: 002b:7ffe50cc0be8 EFLAGS: 0217 ORIG_RAX: 002a RAX: ffda RBX: RCX: 00441c69 RDX: 001c RSI: 208fdfe4 RDI: 0003 RBP: 006cc018 R08: R09: R10: 0538 R11: 0217 R12: 00403590 R13: 00403620 R14: R15: Code: 48 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 46 02 00 00 48 8b 45 c8 44 0f b7 20 e8 88 97 04 fd 31 d2 41 0f b7 c4 4c 89 f9 <41> f7 f6 48 c1 e9 03 48 b8 00 00 00 00 00 fc ff df 0f b6 0c 01 RIP: nf_nat_l4proto_unique_tuple+0x291/0x530 net/netfilter/nf_nat_proto_common.c:88 RSP: 8801b2466778 The problem is that currently we don't have any check on the configured port range. A port range == -1 triggers the bug, while other negative values may require a very long time to complete the following loop. Adding the relevant check at parse time could break existing setup, moreover we would need to read/write such values atomically to avoid possible transient negative ranges at update time. This commit address the issue swapping the two ends on negative ranges in nf_nat_l4proto_unique_tuple(). Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core") Reported-and-tested-by: syzbot+8012e198bd037f487...@syzkaller.appspotmail.com Signed-off-by: Paolo Abeni --- net/netfilter/nf_nat_proto_common.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_nat_proto_common.c b/net/netfilter/nf_nat_proto_common.c index fbce552a796e..a05cce545e98 100644 --- a/net/netfilter/nf_nat_proto_common.c +++ b/net/netfilter/nf_nat_proto_common.c @@ -41,7 +41,7 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto *l3proto, const struct nf_conn *ct, u16 *rover) { - unsigned int range_size, min, i; + unsigned int range_size, min, max, i; __be16 *portptr; u_int16_t off; @@ -70,8 +70,11 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto *l3proto, range_size = 65535 - 1024 + 1; } } else { - min = ntohs(range->min_proto.all); - range_size = ntohs(range->max_proto.all) - min + 1; + min = ntohs(READ_ONCE(range->min_pr
Re: Apply "netfilter: nf_queue: Make the queue_handler pernet" to 4.4-stable
On Fri, Feb 09, 2018 at 04:19:06PM -0800, Eric Biggers wrote: > Hi Greg, can you please apply commit dc3ee32e96d7 ("netfilter: nf_queue: Make > the queue_handler pernet") to 4.4-stable? syzbot is hitting the crash in > nfqnl_nf_hook_drop() by interrupting thread creation in pg_net_init(). An OOM > condition is not required, contrary to what is suggested by the original > commit > message. Now queued up, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netfilter: ipt_ah: return boolean instead of integer
Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- net/ipv4/netfilter/ipt_ah.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/netfilter/ipt_ah.c b/net/ipv4/netfilter/ipt_ah.c index a787d07..7c6c20e 100644 --- a/net/ipv4/netfilter/ipt_ah.c +++ b/net/ipv4/netfilter/ipt_ah.c @@ -47,7 +47,7 @@ static bool ah_mt(const struct sk_buff *skb, struct xt_action_param *par) */ pr_debug("Dropping evil AH tinygram.\n"); par->hotdrop = true; - return 0; + return false; } return spi_match(ahinfo->spis[0], ahinfo->spis[1], -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about UNDEFINE/REDEFINE
Hello Pablo, what do you think about this proposal? -- S pozdravem, David Fabian Cluster Design, s.r.o. Dne úterý 30. ledna 2018 12:05:48 CET, David Fabian napsal(a): > Hello Pablo, > > Dne pátek 26. ledna 2018 14:45:49 CET, Pablo Neira Ayuso napsal(a): > > 2) Probably even cleaner is to look at 'local' scopes like in bash. > > > > define local IP1 = 1.1.1.1 > > > > so the symbol is bound to this file - consider the content of a file > > determines a given scope. This can be also useful to the nested > > notation. > > > > 3) You rework your ruleset to use the notation with nesting :-). But I > > think 2) can be useful for both the flat and nested notation. > > > > I'm not asking you to do 2), but I would like to see how a patch that > > adds explicit scoping for the flat ruleset representation looks like. > > I know about scopes in the code but unfortunately as you said, the flat > notation only has a single scope. Since we are talking about analogy to > bash, bash allows me to redefine a variable in the same scope. Variables in > nftables feel more like constants which is not necessarily bad as it can > prevent some typos but is hard to work with in scripting as it's not that > flexible. > > From those options you listed I would strongly prefer to have an implicit > scope for each file included in the flat notation. That way, defining a > variable in one file would not collide with the same variable in a sibling > include. Variables from outer scopes would still be available in inner > scopes. For people that would want to have their "global" definitions in a > separate include, I would recommend creating a new keyword like global or > export that would tie a variable to the top-level scope and thus make it > available to everyone. I don't think that would be that hard to implement > and I may try to if we agree on it. > > Anyway there should definitely be a way to de-register (undefine) a variable > from a scope to prevent a misuse due to typos. > > By the way, can we restructure the FW using nesting and still be able to > retain all per-customer rules in a single file? Wouldn't that require us to > split prerouting, postrouting, forward and other rules to separate scopes/ > table definitions? That would be highly inconvenient. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html