Message ID | 20210526151129.16141-1-cascardo@canonical.com |
---|---|
Headers | show |
Series | CVE-2021-23133 | expand |
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)