Qingjie Xing <xqjcool@xxxxxxxxx> 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.
