[SRU,Bionic,Groovy,Focal/linux-oem-5.6,Focal/linux-oem-5.10,0/2] CVE-2021-23133

[Impact]
When a SCTP socket fails to be created because of an attached BPF program, a
race might cause a list to be corrupt.

[Fix]
A first fix was submitted and accepted but found to cause potential lockups.
In kernels where this fix has been applied, it was reverted and the second
fix was applied. In other kernels, only the second fix was applied.

[Test]
A reproducer for the list corruption was tested with slub_debug=FZP,SCTP,
because that was the only condition where the corruption could be noticed.
Also, the syzbot reproducer for the lockup was run, though there was no
indication of a lockup on an unpatched kernel.

[Potential regressions]
SCTP asconf might fail to work properly, or lockups might happen when creating
or destroying SCTP sockets.

Xin Long (1):
  Revert "net/sctp: fix race condition in sctp_destroy_sock"
  sctp: delay auto_asconf init until binding the first addr

 net/sctp/socket.c | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

On 26/05/2021 12:11, Thadeu Lima de Souza Cascardo wrote:
> [Impact]
> When a SCTP socket fails to be created because of an attached BPF program, a
> race might cause a list to be corrupt.
> 
> [Fix]
> A first fix was submitted and accepted but found to cause potential lockups.
> In kernels where this fix has been applied, it was reverted and the second
> fix was applied. In other kernels, only the second fix was applied.
> 
> [Test]
> A reproducer for the list corruption was tested with slub_debug=FZP,SCTP,
> because that was the only condition where the corruption could be noticed.
> Also, the syzbot reproducer for the lockup was run, though there was no
> indication of a lockup on an unpatched kernel.
> 
> [Potential regressions]
> SCTP asconf might fail to work properly, or lockups might happen when creating
> or destroying SCTP sockets.
> 
> Xin Long (1):
>   Revert "net/sctp: fix race condition in sctp_destroy_sock"
>   sctp: delay auto_asconf init until binding the first addr
> 
>  net/sctp/socket.c | 31 +++++++++++++++++--------------
>  1 file changed, 17 insertions(+), 14 deletions(-)
> 

Thanks Cascardo, good testing and SRU information!

Acked-by: Guilherme G. Piccoli <gpiccoli@canonical.com>

Acked-by: Tim Gardner <tim.gardner@canonical.com>

On 5/26/21 9:11 AM, Thadeu Lima de Souza Cascardo wrote:
> [Impact]
> When a SCTP socket fails to be created because of an attached BPF program, a
> race might cause a list to be corrupt.
> 
> [Fix]
> A first fix was submitted and accepted but found to cause potential lockups.
> In kernels where this fix has been applied, it was reverted and the second
> fix was applied. In other kernels, only the second fix was applied.
> 
> [Test]
> A reproducer for the list corruption was tested with slub_debug=FZP,SCTP,
> because that was the only condition where the corruption could be noticed.
> Also, the syzbot reproducer for the lockup was run, though there was no
> indication of a lockup on an unpatched kernel.
> 
> [Potential regressions]
> SCTP asconf might fail to work properly, or lockups might happen when creating
> or destroying SCTP sockets.
> 
> Xin Long (1):
>    Revert "net/sctp: fix race condition in sctp_destroy_sock"
>    sctp: delay auto_asconf init until binding the first addr
> 
>   net/sctp/socket.c | 31 +++++++++++++++++--------------
>   1 file changed, 17 insertions(+), 14 deletions(-)
>

On 26.05.21 17:11, Thadeu Lima de Souza Cascardo wrote:
> [Impact]
> When a SCTP socket fails to be created because of an attached BPF program, a
> race might cause a list to be corrupt.
> 
> [Fix]
> A first fix was submitted and accepted but found to cause potential lockups.
> In kernels where this fix has been applied, it was reverted and the second
> fix was applied. In other kernels, only the second fix was applied.
> 
> [Test]
> A reproducer for the list corruption was tested with slub_debug=FZP,SCTP,
> because that was the only condition where the corruption could be noticed.
> Also, the syzbot reproducer for the lockup was run, though there was no
> indication of a lockup on an unpatched kernel.
> 
> [Potential regressions]
> SCTP asconf might fail to work properly, or lockups might happen when creating
> or destroying SCTP sockets.
> 
> Xin Long (1):
>    Revert "net/sctp: fix race condition in sctp_destroy_sock"
>    sctp: delay auto_asconf init until binding the first addr
> 
>   net/sctp/socket.c | 31 +++++++++++++++++--------------
>   1 file changed, 17 insertions(+), 14 deletions(-)
> 


Applied to bionic:linux and groovy:linux.

Just to make sure, this isn't needed for focal:linux?

Thanks,
Kleber

applied to oem-5.6, thanks
Acked-By: AceLan Kao <acelan.kao@canonical.com>

On 26.5.2021 18.11, Thadeu Lima de Souza Cascardo wrote:
> [Impact]
> When a SCTP socket fails to be created because of an attached BPF program, a
> race might cause a list to be corrupt.
> 
> [Fix]
> A first fix was submitted and accepted but found to cause potential lockups.
> In kernels where this fix has been applied, it was reverted and the second
> fix was applied. In other kernels, only the second fix was applied.
> 
> [Test]
> A reproducer for the list corruption was tested with slub_debug=FZP,SCTP,
> because that was the only condition where the corruption could be noticed.
> Also, the syzbot reproducer for the lockup was run, though there was no
> indication of a lockup on an unpatched kernel.
> 
> [Potential regressions]
> SCTP asconf might fail to work properly, or lockups might happen when creating
> or destroying SCTP sockets.
> 
> Xin Long (1):
>    Revert "net/sctp: fix race condition in sctp_destroy_sock"
>    sctp: delay auto_asconf init until binding the first addr
> 
>   net/sctp/socket.c | 31 +++++++++++++++++--------------
>   1 file changed, 17 insertions(+), 14 deletions(-)
> 

already applied via 5.10.37 (LP: #1930557)