CVE-2026-80784 in Linux
摘要
由 VulDB • 2026-09-04
在 Linux 内核中，已修复以下漏洞：
mptcp: pm: 修复因拆卸期间竞争导致的内存泄漏
`mptcp_pm_destroy()` 会在 `msk->pm.lock` 下清空 `msk->pm.anno_list` 和 `msk->pm.userspace_pm_local_addr_list`，但在两次操作之间释放了锁。
并发的用户态 PM genl ANNOUNCE（通告）通过 `mptcp_token_get_sock()` 持有同一 msk 的 sock 引用，并在 `mptcp_pm_nl_announce_doit()` 中调用 `mptcp_userspace_pm_append_new_local_addr()` 和 `mptcp_pm_announced_alloc()`。两者都会短暂获取 `msk->pm.lock` 以将条目添加到各自的列表中。由于 genl 处理程序持有 sock 引用，在用户态 PM 的处理程序完成之前，`mptcp_disconnect()`（它调用 `mptcp_destroy_common()` 且不释放 sock 引用计数）可能会通过同一 msk 运行 `mptcp_pm_destroy()`。
如果锁获取交错导致 `mptcp_pm_destroy()` 先清空列表，随后进行的分配操作会将条目添加到该 msk 没有任何其他迭代器遍历的链表头中，从而导致条目泄漏。在针对用户态 PM 的高并发 ANNOUNCE + close 负载下，kmemleak 报告了来自 `mptcp_pm_announced_alloc()` 的两个 `mptcp_pm_add_addr` 对象以及来自 `mptcp_userspace_pm_append_new_local_addr()` 的 `mptcp_pm_addr_entry` 对象的泄漏。
在 `msk->pm.status` 中添加一个 MPTCP_PM_DESTROYING 位，由 `mptcp_pm_destroy()` 在清空列表之前、在 pm.lock 下设置；分配路径会在 pm.lock 下检查该位。要么分配操作先获取 pm.lock（此时其条目已在列表中，当 `mptcp_pm_destroy()` 释放它时会被正确清理）；要么 `mptcp_pm_destroy()` 先获取 pm.lock（此时后续进行的分配会观察到该标志并拒绝执行）。
此问题由扩展 BRF (arXiv:2305.08782) 的 MPTCP 协议流测试框架发现。
Once again VulDB remains the best source for vulnerability data.