CVE-2026-46170
Received Received - Intake
Memory Leak in Linux Kernel MPTCP PM

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself".
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :

This vulnerability in the Linux kernel relates to the handling of the ADD_ADDR retransmission in the mptcp (Multipath TCP) protocol. Specifically, it involves improper freeing of socket references which can lead to indefinite waiting in the timer handling code. This could potentially cause resource leaks or system instability due to sockets not being freed properly.


Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's multipath TCP (mptcp) implementation, specifically related to the handling of ADD_ADDR retransmissions.

When an ADD_ADDR message is retransmitted, a socket (sk) is held in a reset timer function and released at the end. If this socket is the last reference being held, it is not properly freed because the wrong function (__sock_put()) is called instead of sock_put().

However, calling sock_put() on the last reference leads to a deadlock situation because it calls sk_free(), which tries to stop the timer synchronously on itself, causing an indefinite wait.

The fix involves marking the timer as done at the end of the timer handler if it has not been rescheduled, preventing the deadlock by avoiding calling sk_stop_timer_sync() on the same timer.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart