ACK/Cmnt: [SRU][J][PATCH v3 0/2] CVE-2026-53246

[Manuel Diewald]

On Thu, Aug 06, 2026 at 12:49:29PM +0300, Mehmet Basaran via kernel-team wrote:
> https://ubuntu.com/security/CVE-2026-53246
> 
> [Impact]
> 
> ubuntu_ltp_syscalls:bind04 test timeouts on openstack vms while trying
> to establish a stcp connections regardless of the architecture:
> 
>   bind04.c:117: TINFO: Testing AF_UNIX pathname stream
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing AF_UNIX pathname seqpacket
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing AF_UNIX abstract stream
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing AF_UNIX abstract seqpacket
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing IPv4 loop TCP variant 1
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing IPv4 loop TCP variant 2
>   bind04.c:149: TPASS: Communication successful
>   bind04.c:117: TINFO: Testing IPv4 loop SCTP
>   Test timeouted, sending SIGKILL!
>   tst_test.c:1928: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
>   tst_test.c:1930: TBROK: Test killed! (timeout?)
> 
> [Fix]
> 
> git bisect reveals that breaking commit was applied with CVE-2026-53246:
> 
>   Upstream commit: 0861615c28de668669d748ef4eb913ea9262d13b
>   sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing
> 
> keybele missed the following dependency while backporting:
> 
>   Upstream commit: 0861615c28de668669d748ef4eb913ea9262d13b
>   sctp: delete the nested flexible array peer_init
> 
> Basically dependency patch removes the last field "peer_init" from
> struct sctp_cookie (include/net/sctp/structs.h) but the data is still
> appended at the end and accesses to that data with
> "(struct sctp_cookie *) + 1".
> 
> Breaking commit tries to access this data with the same pointer math
> however, since "peer_init" field is not removed from struct sctp_cookie
> it ends up accessing to a different memory address.
> 
> An alternative way to solve the issue is to use a sauce patch with the
> following change:
> 
>   --- a/net/sctp/sm_make_chunk.c
>   +++ b/net/sctp/sm_make_chunk.c
>   @@ -1780,6 +1780,6 @@ struct sctp_association *sctp_unpack_cookie(
>           cookie = chunk->subh.cookie_hdr;
>           bear_cookie = &cookie->c;
> 
>   -       ch = (struct sctp_chunkhdr *)(bear_cookie + 1);
>   +       ch = (struct sctp_chunkhdr *) &cookie->c.peer_init[0];
>           if (ntohs(ch->length) > len - fixed_size)
> 
> [Test Plan]
> 
> Both solutions above work. Tested it by building a new kernel and trying
> it on openstack:amd64-vm.
> 
> In this submission, I went with applying the missing patch instead so
> that we don't deviate from the upstream sources.
> 
> [Where problems could occur]
> 
> This change is related the inital handshaking phase of sctp. There
> shouldn't be any sideaffects of this change, after the handshake
> completes.
> 
> Moreover, "sctp: delete the nested flexible array peer_init" removes
> "peer_init" from struct sctp_cookie and replaces all the accesses no
> risk is involved with this change.
> 
> 
> Xin Long (2):
>   sctp: delete the nested flexible array peer_init
>   sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing
> 
>  include/net/sctp/structs.h | 2 +-
>  net/sctp/associola.c       | 5 +++--
>  net/sctp/sm_make_chunk.c   | 9 +++++++--
>  net/sctp/sm_statefuns.c    | 8 +++-----
>  4 files changed, 14 insertions(+), 10 deletions(-)
> 
> --
> 2.43.0
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team


I'm assuming we will skip the second patch since it's already applied.

Acked-by: Manuel Diewald <manuel.diewald at canonical.com>

-- 
 Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260806/33f6df37/attachment.sig>