From: Nikolay Aleksandrov <nikolay@redhat.com>
To: Florian Westphal <fw@strlen.de>
Cc: netdev@vger.kernel.org,
Jesper Dangaard Brouer <brouer@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] net: fix for a race condition in the inet frag code
Date: Mon, 03 Mar 2014 15:43:00 +0100 [thread overview]
Message-ID: <531494F4.4030909@redhat.com> (raw)
In-Reply-To: <20140303144026.GH9965@breakpoint.cc>
On 03/03/2014 03:40 PM, Florian Westphal wrote:
> Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>> I stumbled upon this very serious bug while hunting for another one,
>> it's a very subtle race condition between inet_frag_evictor,
>> inet_frag_intern and the IPv4/6 frag_queue and expire functions (basically
>> the users of inet_frag_kill/inet_frag_put).
>> What happens is that after a fragment has been added to the hash chain but
>> before it's been added to the lru_list (inet_frag_lru_add), it may get
>> deleted (either by an expired timer if the system load is high or the
>> timer sufficiently low, or by the fraq_queue function for different
>> reasons) before it's added to the lru_list
>
> Sorry. Not following here, see below.
>
>> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
>> index bb075fc9a14f..322dcebfc588 100644
>> --- a/net/ipv4/inet_fragment.c
>> +++ b/net/ipv4/inet_fragment.c
>> @@ -278,9 +278,10 @@ static struct inet_frag_queue *inet_frag_intern(struct netns_frags *nf,
>>
>> atomic_inc(&qp->refcnt);
>> hlist_add_head(&qp->list, &hb->chain);
>> + inet_frag_lru_add(nf, qp);
>> spin_unlock(&hb->chain_lock);
>> read_unlock(&f->lock);
>
> If I understand correctly your're saying that qp can be free'd on
> another/cpu timer right after dropping the locks. But how is it
> possible?
>
> ->refcnt is bumped above when arming the timer (before dropping chain
> lock), so even if the frag_expire timer fires instantly it should not
> free qp.
>
> What am I missing?
>
> Thanks,
> Florian
>
inet_frag_kill when called from the IPv4/6 frag_queue function will remove the
timer refcount, then inet_frag_put afterwards will drop it to 0 and free it and
all of this could happen before the frag was ever added to the LRU list, then it
gets added. This happens much easier for IPv6 because of the dropping of
overlapping fragments in its frag_queue function, the point is we need to have
the timer's refcount removed in any way (it could be the timer itself - there's
an inet_frag_put in the end, or much easier by the frag_queue function).
I think I've explained it badly, I hope this makes it clearer :-)
Cheers,
Nik
next prev parent reply other threads:[~2014-03-03 14:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 14:05 [PATCH] net: fix for a race condition in the inet frag code Nikolay Aleksandrov
2014-03-03 14:40 ` Florian Westphal
2014-03-03 14:43 ` Nikolay Aleksandrov [this message]
2014-03-03 17:13 ` Jesper Dangaard Brouer
2014-03-03 14:49 ` Nikolay Aleksandrov
2014-03-03 15:31 ` Jesper Dangaard Brouer
2014-03-03 15:34 ` Nikolay Aleksandrov
2014-03-03 17:17 ` Florian Westphal
2014-03-03 21:34 ` David Miller
2014-03-03 22:19 ` [PATCH v2] " Nikolay Aleksandrov
2014-03-03 22:21 ` Florian Westphal
2014-03-04 7:28 ` Jesper Dangaard Brouer
2014-03-06 1:34 ` David Miller
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=531494F4.4030909@redhat.com \
--to=nikolay@redhat.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=netdev@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).