Re: [PATCH net 0/7] mptcp: fixes for 6.3

[Matthieu Baerts <matthieu.baerts@tessares.net>]

Hello,

On 27/02/2023 18:29, Matthieu Baerts wrote:
> Patch 1 fixes a possible deadlock in subflow_error_report() reported by
> lockdep. The report was in fact a false positive but the modification
> makes sense and silences lockdep to allow syzkaller to find real issues.
> The regression has been introduced in v5.12.
> 
> Patch 2 is a refactoring needed to be able to fix the two next issues.
> It improves the situation and can be backported up to v6.0.
> 
> Patches 3 and 4 fix UaF reported by KASAN. It fixes issues potentially
> visible since v5.7 and v5.19 but only reproducible until recently
> (v6.0). These two patches depend on patch 2/7.
> 
> Patch 5 fixes the order of the printed values: expected vs seen values.
> The regression has been introduced recently: present in Linus' tree but
> not in a tagged version yet.
> 
> Patch 6 adds missing ro_after_init flags. A previous patch added them
> for other functions but these two have been missed. This previous patch
> has been backported to stable versions (up to v5.12) so probably better
> to do the same here.
> 
> Patch 7 fixes tcp_set_state() being called twice in a row since v5.10.

I'm sorry to ask for that but is it possible not to apply these patches?

> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> ---
> Geliang Tang (1):
>       mptcp: add ro_after_init for tcp{,v6}_prot_override
> 
> Matthieu Baerts (2):
>       selftests: mptcp: userspace pm: fix printed values
>       mptcp: avoid setting TCP_CLOSE state twice
> 
> Paolo Abeni (4):
>       mptcp: fix possible deadlock in subflow_error_report
>       mptcp: refactor passive socket initialization
>       mptcp: use the workqueue to destroy unaccepted sockets

After 3 weeks of validation, syzkaller found an issue with this patch:

  https://github.com/multipath-tcp/mptcp_net-next/issues/366

We then need to NAK this series. We will send a v2 with a fix for that.

>       mptcp: fix UaF in listener shutdown

The other patches of the series are either not very important or are
linked to the "faulty" one: they can all wait as well.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net