[PATCH net 1/2] tcp: avoid wrapping Fast Open blackhole timeout

[PATCH net 1/2] tcp: avoid wrapping Fast Open blackhole timeout

[Yingjie Wang]

tcp_fastopen_active_should_disable() calculates the active-disable
interval as multiplier * tfo_bh_timeout * HZ. Since all operands are
32-bit, a large tcp_fastopen_blackhole_timeout_sec can wrap the delay
even on 64-bit kernels and re-enable active Fast Open too soon.

For example, with HZ=1000, a timeout of 6912213 seconds and the maximum
multiplier of 64 should produce 442381632000 jiffies, but the current
calculation truncates it to 512 jiffies.

This issue was found using a static analysis tool. A loopback reproducer
induced 12 Fast Open blackholes and waited 1.2 seconds before opening
another connection. The unpatched kernel retried active Fast Open, while
the patched kernel kept Fast Open disabled and used a regular TCP
handshake. The reproducer required neither kernel modifications nor
fault injection.

Compute the interval in u64 and cap it at MAX_JIFFY_OFFSET before adding
it to the saved timestamp. This preserves the existing exponential
backoff for representable intervals and prevents large values from
wrapping into short timeouts.

Fixes: cf1ef3f0719b ("net/tcp_fastopen: Disable active side TFO in certain scenarios")
Cc: stable@vger.kernel.org
Signed-off-by: Yingjie Wang <x-professor@outlook.com>
---
 net/ipv4/tcp_fastopen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 7f7eb3cc1c04..aeefd605414f 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -613,6 +613,7 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
 	unsigned long timeout;
 	int tfo_da_times;
 	int multiplier;
+	u64 delay;
 
 	if (!tfo_bh_timeout)
 		return false;
@@ -626,10 +627,11 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
 
 	/* Limit timeout to max: 2^6 * initial timeout */
 	multiplier = 1 << min(tfo_da_times - 1, 6);
+	delay = (u64)multiplier * tfo_bh_timeout * HZ;
 
 	/* Paired with the WRITE_ONCE() in tcp_fastopen_active_disable(). */
 	timeout = READ_ONCE(sock_net(sk)->ipv4.tfo_active_disable_stamp) +
-		  multiplier * tfo_bh_timeout * HZ;
+		  min(delay, MAX_JIFFY_OFFSET);
 	if (time_before(jiffies, timeout))
 		return true;
 
-- 
2.43.0

Re: [PATCH net 1/2] tcp: avoid wrapping Fast Open blackhole timeout

[Kuniyuki Iwashima]

On Tue, 10 Nov 2026 15:47:58 +0000, Yingjie Wang wrote:
> tcp_fastopen_active_should_disable() calculates the active-disable
> interval as multiplier * tfo_bh_timeout * HZ. Since all operands are
> 32-bit, a large tcp_fastopen_blackhole_timeout_sec can wrap the delay
> even on 64-bit kernels and re-enable active Fast Open too soon.
> 
> For example, with HZ=1000, a timeout of 6912213 seconds and the maximum

No one wants to configure 80 days blackhole timeout.

Please apply a sane limit in proc_tfo_blackhole_detect_timeout().

---
pw-bot: cr


> multiplier of 64 should produce 442381632000 jiffies, but the current
> calculation truncates it to 512 jiffies.
> 
> This issue was found using a static analysis tool. A loopback reproducer
> induced 12 Fast Open blackholes and waited 1.2 seconds before opening
> another connection. The unpatched kernel retried active Fast Open, while
> the patched kernel kept Fast Open disabled and used a regular TCP
> handshake. The reproducer required neither kernel modifications nor
> fault injection.
> 
> Compute the interval in u64 and cap it at MAX_JIFFY_OFFSET before adding
> it to the saved timestamp. This preserves the existing exponential
> backoff for representable intervals and prevents large values from
> wrapping into short timeouts.
> 
> Fixes: cf1ef3f0719b ("net/tcp_fastopen: Disable active side TFO in certain scenarios")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <x-professor@outlook.com>
> ---
>  net/ipv4/tcp_fastopen.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> index 7f7eb3cc1c04..aeefd605414f 100644
> --- a/net/ipv4/tcp_fastopen.c
> +++ b/net/ipv4/tcp_fastopen.c
> @@ -613,6 +613,7 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
>  	unsigned long timeout;
>  	int tfo_da_times;
>  	int multiplier;
> +	u64 delay;
>  
>  	if (!tfo_bh_timeout)
>  		return false;
> @@ -626,10 +627,11 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
>  
>  	/* Limit timeout to max: 2^6 * initial timeout */
>  	multiplier = 1 << min(tfo_da_times - 1, 6);
> +	delay = (u64)multiplier * tfo_bh_timeout * HZ;
>  
>  	/* Paired with the WRITE_ONCE() in tcp_fastopen_active_disable(). */
>  	timeout = READ_ONCE(sock_net(sk)->ipv4.tfo_active_disable_stamp) +
> -		  multiplier * tfo_bh_timeout * HZ;
> +		  min(delay, MAX_JIFFY_OFFSET);
>  	if (time_before(jiffies, timeout))
>  		return true;
>  
> -- 
> 2.43.0
> 

[PATCH net 2/2] mptcp: avoid wrapping blackhole timeout

[Yingjie Wang]

mptcp_active_should_disable() calculates the active-disable interval as
multiplier * blackhole_timeout * HZ. Since all operands are 32-bit, a
large blackhole_timeout can wrap the delay even on 64-bit kernels and
make active MPTCP available again while the blackhole is still present.

For example, with HZ=1000, a timeout of 6912213 seconds and the maximum
multiplier of 64 should produce 442381632000 jiffies, but the current
calculation truncates it to 512 jiffies.

This issue was found using a static analysis tool. A loopback reproducer
induced 12 MPTCP blackholes and waited 1.2 seconds before opening another
connection. The unpatched kernel retried MP_CAPABLE, while the patched
kernel kept MPTCP disabled and used TCP fallback directly. The reproducer
required neither kernel modifications nor fault injection.

Compute the interval in u64 and cap it at MAX_JIFFY_OFFSET before adding
it to the saved timestamp. This preserves the existing exponential
backoff for representable intervals and prevents large values from
wrapping into short timeouts.

Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
Cc: stable@vger.kernel.org
Signed-off-by: Yingjie Wang <x-professor@outlook.com>
---
 net/mptcp/ctrl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
index 63c5747f0f63..5224cfb3ed1f 100644
--- a/net/mptcp/ctrl.c
+++ b/net/mptcp/ctrl.c
@@ -487,6 +487,7 @@ bool mptcp_active_should_disable(struct sock *ssk)
 	unsigned long timeout;
 	int disable_times;
 	int multiplier;
+	u64 delay;
 
 	pernet = mptcp_get_pernet(net);
 	blackhole_timeout = READ_ONCE(pernet->blackhole_timeout);
@@ -503,10 +504,11 @@ bool mptcp_active_should_disable(struct sock *ssk)
 
 	/* Limit timeout to max: 2^6 * initial timeout */
 	multiplier = 1 << min(disable_times - 1, 6);
+	delay = (u64)multiplier * blackhole_timeout * HZ;
 
 	/* Paired with the WRITE_ONCE() in mptcp_active_disable(). */
 	timeout = READ_ONCE(pernet->active_disable_stamp) +
-		  multiplier * blackhole_timeout * HZ;
+		  min(delay, MAX_JIFFY_OFFSET);
 
 	return time_before(jiffies, timeout);
 }
-- 
2.43.0

Re: [PATCH net 2/2] mptcp: avoid wrapping blackhole timeout

[gang.yan]

> 
> mptcp_active_should_disable() calculates the active-disable interval as
> multiplier * blackhole_timeout * HZ. Since all operands are 32-bit, a
> large blackhole_timeout can wrap the delay even on 64-bit kernels and
> make active MPTCP available again while the blackhole is still present.
> 
> For example, with HZ=1000, a timeout of 6912213 seconds and the maximum
> multiplier of 64 should produce 442381632000 jiffies, but the current
> calculation truncates it to 512 jiffies.
> 
> This issue was found using a static analysis tool. A loopback reproducer
> induced 12 MPTCP blackholes and waited 1.2 seconds before opening another
> connection. The unpatched kernel retried MP_CAPABLE, while the patched
> kernel kept MPTCP disabled and used TCP fallback directly. The reproducer
> required neither kernel modifications nor fault injection.
> 
> Compute the interval in u64 and cap it at MAX_JIFFY_OFFSET before adding
> it to the saved timestamp. This preserves the existing exponential
> backoff for representable intervals and prevents large values from
> wrapping into short timeouts.
> 
> Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <x-professor@outlook.com>
> ---
>  net/mptcp/ctrl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
> index 63c5747f0f63..5224cfb3ed1f 100644
> --- a/net/mptcp/ctrl.c
> +++ b/net/mptcp/ctrl.c
> @@ -487,6 +487,7 @@ bool mptcp_active_should_disable(struct sock *ssk)
>  unsigned long timeout;
>  int disable_times;
>  int multiplier;
> + u64 delay;
>  
>  pernet = mptcp_get_pernet(net);
>  blackhole_timeout = READ_ONCE(pernet->blackhole_timeout);
> @@ -503,10 +504,11 @@ bool mptcp_active_should_disable(struct sock *ssk)
>  
>  /* Limit timeout to max: 2^6 * initial timeout */
>  multiplier = 1 << min(disable_times - 1, 6);
> + delay = (u64)multiplier * blackhole_timeout * HZ;
>  

Hi Yingjie,

Thanks for the patch. Basically LGTM, 


Just two small questions:

>  /* Paired with the WRITE_ONCE() in mptcp_active_disable(). */
>  timeout = READ_ONCE(pernet->active_disable_stamp) +
> - multiplier * blackhole_timeout * HZ;
> + min(delay, MAX_JIFFY_OFFSET);

1. AFAICS, on 64bit machine, the largest possible delay is 64 * INT_MAX * HZ, far
less than MAX_JIFFY_OFFSET ((LONG_MAX >> 1) - 1 = 2^62 - 2). So is the min() intended for the
32-bit machine? 

2. If so, should the comment be updated? Because there is a second timeout on 32-bit machine.


Thanks
Gang

Reviewed-by: Gang Yan <yangang@kylinos.cn>

>  
>  return time_before(jiffies, timeout);
>  }
> -- 
> 2.43.0
>