From: Greg KH <gregkh@linuxfoundation.org>
To: pabeni@redhat.com, fw@strlen.de, pablo@netfilter.org
Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org
Subject: Re: Patch "netfilter: drop template ct when conntrack is skipped." has been added to the 4.4-stable tree
Date: Tue, 3 Apr 2018 19:25:16 +0200 [thread overview]
Message-ID: <20180403172516.GB29406@kroah.com> (raw)
In-Reply-To: <15227741671826@kroah.com>
Also dropped, sorry.
greg k-h
On Tue, Apr 03, 2018 at 06:49:27PM +0200, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> netfilter: drop template ct when conntrack is skipped.
>
> to the 4.4-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> netfilter-drop-template-ct-when-conntrack-is-skipped.patch
> and it can be found in the queue-4.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
>
> >From aebfa52a925d701114afd6af0def35bab16d4f47 Mon Sep 17 00:00:00 2001
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Thu, 22 Mar 2018 11:08:50 +0100
> Subject: netfilter: drop template ct when conntrack is skipped.
>
> From: Paolo Abeni <pabeni@redhat.com>
>
> commit aebfa52a925d701114afd6af0def35bab16d4f47 upstream.
>
> The ipv4 nf_ct code currently skips the nf_conntrak_in() call
> for fragmented packets. As a results later matches/target can end
> up manipulating template ct entry instead of 'real' ones.
>
> Exploiting the above, syzbot found a way to trigger the following
> splat:
>
> WARNING: CPU: 1 PID: 4242 at net/netfilter/xt_cluster.c:55
> xt_cluster_mt+0x6c1/0x840 net/netfilter/xt_cluster.c:127
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 4242 Comm: syzkaller027971 Not tainted 4.16.0-rc2+ #243
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x58/0x80 arch/x86/entry/entry_64.S:957
> RIP: 0010:xt_cluster_hash net/netfilter/xt_cluster.c:55 [inline]
> RIP: 0010:xt_cluster_mt+0x6c1/0x840 net/netfilter/xt_cluster.c:127
> RSP: 0018:ffff8801d2f6f2d0 EFLAGS: 00010293
> RAX: ffff8801af700540 RBX: 0000000000000000 RCX: ffffffff84a2d1e1
> RDX: 0000000000000000 RSI: ffff8801d2f6f478 RDI: ffff8801cafd336a
> RBP: ffff8801d2f6f2e8 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b03b3d18
> R13: ffff8801cafd3300 R14: dffffc0000000000 R15: ffff8801d2f6f478
> ipt_do_table+0xa91/0x19b0 net/ipv4/netfilter/ip_tables.c:296
> iptable_filter_hook+0x65/0x80 net/ipv4/netfilter/iptable_filter.c:41
> 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]
> raw_send_hdrinc.isra.17+0xf39/0x1880 net/ipv4/raw.c:432
> raw_sendmsg+0x14cd/0x26b0 net/ipv4/raw.c:669
> inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:639
> SYSC_sendto+0x361/0x5c0 net/socket.c:1748
> SyS_sendto+0x40/0x50 net/socket.c:1716
> do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x441b49
> RSP: 002b:00007ffff5ca8b18 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441b49
> RDX: 0000000000000030 RSI: 0000000020ff7000 RDI: 0000000000000003
> RBP: 00000000006cc018 R08: 000000002066354c R09: 0000000000000010
> R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000403470
> R13: 0000000000403500 R14: 0000000000000000 R15: 0000000000000000
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
> Instead of adding checks for template ct on every target/match
> manipulating skb->_nfct, simply drop the template ct when skipping
> nf_conntrack_in().
>
> Fixes: 7b4fdf77a450ec ("netfilter: don't track fragmented packets")
> Reported-and-tested-by: syzbot+0346441ae0545cfcea3a@syzkaller.appspotmail.com
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> Acked-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
> +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
> @@ -159,8 +159,20 @@ static unsigned int ipv4_conntrack_local
> ip_hdrlen(skb) < sizeof(struct iphdr))
> return NF_ACCEPT;
>
> - if (ip_is_fragment(ip_hdr(skb))) /* IP_NODEFRAG setsockopt set */
> + if (ip_is_fragment(ip_hdr(skb))) { /* IP_NODEFRAG setsockopt set */
> + enum ip_conntrack_info ctinfo;
> + struct nf_conn *tmpl;
> +
> + tmpl = nf_ct_get(skb, &ctinfo);
> + if (tmpl && nf_ct_is_template(tmpl)) {
> + /* when skipping ct, clear templates to avoid fooling
> + * later targets/matches
> + */
> + skb->_nfct = 0;
> + nf_ct_put(tmpl);
> + }
> return NF_ACCEPT;
> + }
>
> return nf_conntrack_in(state->net, PF_INET, state->hook, skb);
> }
>
>
> Patches currently in stable-queue which might be from pabeni@redhat.com are
>
> queue-4.4/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
prev parent reply other threads:[~2018-04-03 17:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 16:49 Patch "netfilter: drop template ct when conntrack is skipped." has been added to the 4.4-stable tree gregkh
2018-04-03 17:25 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180403172516.GB29406@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=fw@strlen.de \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).