linux-kernel - Re: [PATCH] netfilter: conntrack: drop expectations before freeing templates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aKbIUQ3a3jqijZi0@strlen.de>
Date: Thu, 21 Aug 2025 09:18:41 +0200
From: Florian Westphal <fw@...len.de>
To: Qingjie Xing <xqjcool@...il.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] netfilter: conntrack: drop expectations before freeing
 templates

Qingjie Xing <xqjcool@...il.com> wrote:
> I added a panic() in nf_ct_expect_insert(). After reproducing, the crash dump 
> (via crash) shows the nf_conntrack involved is a template (used as the master), 
> and the expectation insertion was triggered by a TFTP packet.

The tftp packet should be associated with a conntrack entry, not a
template.

>  #3 [ffffc9001762b9c8] nf_ct_expect_related_report at ffffffff80ee7b27
>  #4 [ffffc9001762ba40] tftp_help at ffffffff80f001ea
>  #5 [ffffc9001762ba98] nf_confirm at ffffffff80eeaa77
>  #6 [ffffc9001762bac8] ipv4_confirm at ffffffff80eeafa9
>  #7 [ffffc9001762baf8] nf_hook_slow at ffffffff80ed24db
>  #8 [ffffc9001762bb40] ip_output at ffffffff80fe85a5
>  #9 [ffffc9001762bbc8] udp_send_skb at ffffffff81033372
> #10 [ffffc9001762bc18] udp_sendmsg at ffffffff81032cb2
> #11 [ffffc9001762bd90] inet_sendmsg at ffffffff810488a1

How can this happen?

1. -t raw assigns skb->_nfct to the template.
2. at OUTPUT, nf_conntrack_in is called:

unsigned int
nf_conntrack_in(struct sk_buff *skb, const struct nf_hook_state *state)
{
        enum ip_conntrack_info ctinfo;
        struct nf_conn *ct, *tmpl;
        u_int8_t protonum;
        int dataoff, ret;

        tmpl = nf_ct_get(skb, &ctinfo);
        if (tmpl || ctinfo == IP_CT_UNTRACKED) {
                /* Previously seen (loopback or untracked)?  Ignore. */
                if ((tmpl && !nf_ct_is_template(tmpl)) ||
                     ctinfo == IP_CT_UNTRACKED)
                        return NF_ACCEPT;
                skb->_nfct = 0; // HERE
        }

... and that will *clear* the template again.

3. nf_conntrack_in assigns skb->_nfct to a newly allocated
   connrack (not a template).

The backtrace you quote should be impossible.

You need to figure out why skb->_nfct was not cleared by
nf_conntrack_in().

You did not mention anything about timing, does this only
happen at the start, i.e. do we have a race where nf_confirm
was just registered with nf_hook_slow for the first time but
ipv4_confirm wasn't set up yet?

If so, please fix nf_confirm() to return early if the skb
has a template attached.