[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmho7cbf33q.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Tue, 20 Feb 2024 18:38:17 +0100
From: Valentin Schneider <vschneid@...hat.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: dccp@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org, "David S.
Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo
Abeni <pabeni@...hat.com>, mleitner@...hat.com, David Ahern
<dsahern@...nel.org>, Juri Lelli <juri.lelli@...hat.com>, Tomas Glozar
<tglozar@...hat.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/1] tcp/dcpp: Un-pin tw_timer
On 19/02/24 15:42, Eric Dumazet wrote:
> On Mon, Feb 19, 2024 at 10:57 AM Valentin Schneider <vschneid@...hat.com> wrote:
>>
>> The TCP timewait timer is proving to be problematic for setups where scheduler
>> CPU isolation is achieved at runtime via cpusets (as opposed to statically via
>> isolcpus=domains).
>>
>
> ...
>
>> void inet_twsk_deschedule_put(struct inet_timewait_sock *tw)
>> {
>> + /* This can race with tcp_time_wait() and dccp_time_wait(), as the timer
>> + * is armed /after/ adding it to the hashtables.
>> + *
>> + * If this is interleaved between inet_twsk_hashdance() and inet_twsk_put(),
>> + * then this is a no-op: the timer will still end up armed.
>> + *
>> + * Conversely, if this successfully deletes the timer, then we know we
>> + * have already gone through {tcp,dcpp}_time_wait(), and we can safely
>> + * call inet_twsk_kill().
>> + */
>> if (del_timer_sync(&tw->tw_timer))
>> inet_twsk_kill(tw);
>
> I really do not think adding a comment will prevent races at netns dismantle.
>
> We need to make sure the timer is not rearmed, we want to be absolutely
> sure that after inet_twsk_purge() we have no pending timewait sockets,
> otherwise UAF will happen on the netns structures.
>
> I _think_ that you need timer_shutdown_sync() here, instead of del_timer_sync()
Hm so that would indeed prevent a concurrent inet_twsk_schedule() from
re-arming the timer, but in case the calls are interleaved like so:
tcp_time_wait()
inet_twsk_hashdance()
inet_twsk_deschedule_put()
timer_shutdown_sync()
inet_twsk_schedule()
inet_twsk_hashdance() will have left the refcounts including a count for
the timer, and we won't arm the timer to clear it via the timer callback
(via inet_twsk_kill()) - the patch in its current form relies on the timer
being re-armed for that.
I don't know if there's a cleaner way to do this, but we could catch that
in inet_twsk_schedule() and issue the inet_twsk_kill() directly if we can
tell the timer has been shutdown:
---
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index 61a053fbd329c..c272da5046bb4 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -227,7 +227,7 @@ void inet_twsk_deschedule_put(struct inet_timewait_sock *tw)
* have already gone through {tcp,dcpp}_time_wait(), and we can safely
* call inet_twsk_kill().
*/
- if (del_timer_sync(&tw->tw_timer))
+ if (timer_shutdown_sync(&tw->tw_timer))
inet_twsk_kill(tw);
inet_twsk_put(tw);
}
@@ -267,6 +267,10 @@ void __inet_twsk_schedule(struct inet_timewait_sock *tw, int timeo, bool rearm)
LINUX_MIB_TIMEWAITED);
BUG_ON(mod_timer(&tw->tw_timer, jiffies + timeo));
refcount_inc(&tw->tw_dr->tw_refcount);
+
+ /* XXX timer got shutdown */
+ if (!tw->tw_timer.function)
+ inet_twsk_kill(tw);
} else {
mod_timer_pending(&tw->tw_timer, jiffies + timeo);
}
Powered by blists - more mailing lists