Hi Paolo,
On 21/12/2024 09:51, Paolo Abeni wrote:
Syzbot reported the following splat:
(...)
Eric noted a probable shinfo->nr_frags corruption, which indeed occurs.
The root cause is a buggy MPTCP option len computation in some circumstances: the ADD_ADDR option should be mutually exclusive with DSS since the blamed commit.
Still, mptcp_established_options_add_addr() tries to set the relevant info in mptcp_out_options, if the remaining space is large enough even when DSS is present.
Since the ADD_ADDR infos and the DSS share the same union fields, adding first corrupts the latter. In the worst-case scenario, such corruption increases the DSS binary layout, exceeding the computed length and possibly overwriting the skb shared info.
Address the issue by enforcing mutual exclusion in mptcp_established_options_add_addr(), too.
Thank you for the investigation and the fix, it looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) matttbe@kernel.org
Reported-by: syzbot+38a095a81f30d82884c1@syzkaller.appspotmail.com
If you don't mind, can you please add these two tags when applying the patches to help to track the backports?
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/538 Cc: stable@vger.kernel.org
Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Signed-off-by: Paolo Abeni pabeni@redhat.com
Cheers, Matt