Commit efbb6ba
mptcp: pm: fix data race in add_addr timer callback
[ Upstream commit a7aad5b ]
The timer callback reads entry->retrans_times outside pm.lock to decide
whether to call mptcp_pm_subflow_established(). Since
mptcp_pm_announced_del_timer() can concurrently set retrans_times =
ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists.
I discovered this issue while studying the code. AI tools helped me to
verify the issue can potentially happen under race conditions.
Use a local 'retransmit' flag set inside pm.lock to capture whether
retransmission is still possible when the lock is taken. This allows to
call mptcp_pm_subflow_established() accordingly, and not depending on
the situation that can be different when checked outside the pm.lock.
Fixes: 348d5c1 ("mptcp: move to next addr when timeout")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Luo <luoqing@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ applied hunk to mptcp_pm_add_timer() in net/mptcp/pm_netlink.c instead of pm.c, dropping the absent adaptive-timeout shift line ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>1 parent 1f26487 commit efbb6ba
1 file changed
Lines changed: 4 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
318 | 318 | | |
319 | 319 | | |
320 | 320 | | |
| 321 | + | |
321 | 322 | | |
322 | 323 | | |
323 | 324 | | |
| |||
355 | 356 | | |
356 | 357 | | |
357 | 358 | | |
358 | | - | |
| 359 | + | |
| 360 | + | |
359 | 361 | | |
360 | 362 | | |
361 | 363 | | |
362 | 364 | | |
363 | | - | |
| 365 | + | |
364 | 366 | | |
365 | 367 | | |
366 | 368 | | |
| |||
0 commit comments