CVE-2024-45010

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only mark &amp;#39;subflow&amp;#39; endp as available<br /> <br /> Adding the following warning ...<br /> <br /> WARN_ON_ONCE(msk-&gt;pm.local_addr_used == 0)<br /> <br /> ... before decrementing the local_addr_used counter helped to find a bug<br /> when running the "remove single address" subtest from the mptcp_join.sh<br /> selftests.<br /> <br /> Removing a &amp;#39;signal&amp;#39; endpoint will trigger the removal of all subflows<br /> linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with<br /> rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used<br /> counter, which is wrong in this case because this counter is linked to<br /> &amp;#39;subflow&amp;#39; endpoints, and here it is a &amp;#39;signal&amp;#39; endpoint that is being<br /> removed.<br /> <br /> Now, the counter is decremented, only if the ID is being used outside<br /> of mptcp_pm_nl_rm_addr_or_subflow(), only for &amp;#39;subflow&amp;#39; endpoints, and<br /> if the ID is not 0 -- local_addr_used is not taking into account these<br /> ones. This marking of the ID as being available, and the decrement is<br /> done no matter if a subflow using this ID is currently available,<br /> because the subflow could have been closed before.