mptcp: pm: ADD_ADDR 0 is not a new address
commit 57f86203 upstream. The ADD_ADDR 0 with the address from the initial subflow should not be considered as a new address: this is not something new. If the host receives it, it simply means that the address is available again. When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider it as new by not incrementing the 'add_addr_accepted' counter. But the 'accept_addr' might not be set if the limit has already been reached: this can be bypassed in this case. But before, it is important to check that this ADD_ADDR for the ID 0 is for the same address as the initial subflow. If not, it is not something that should happen, and the ADD_ADDR can be ignored. Note that if an ADD_ADDR is received while there is already a subflow opened using the same address, this ADD_ADDR is ignored as well. It means that if multiple ADD_ADDR for ID 0 are received, there will not be any duplicated subflows created by the client. Fixes: d0876b22 ("mptcp: add the incoming RM_ADDR support") Cc: stable@vger.kernel.org Reviewed-by:Mat Martineau <martineau@kernel.org> Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> [ Conflicts in pm.c, due to commit 4d25247d ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs"), which is not in this version, and changes the context. The same fix can be applied here by adding the new check at the same place. Note that addresses_equal() has been used instead of mptcp_addresses_equal(), renamed in commit 4638de5a ("mptcp: handle local addrs announced by userspace PMs"), not in this version. ] Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Loading