On Sat, Dec 21, 2024 at 11:28 AM Matthieu Baerts <matttbe@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> > > > Reported-by: syzbot+38a095a81f30d82884c1@xxxxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxx > Thanks for the fix ! Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>
