sctp: COOKIE_ECHO can cause an out-of-bounds read and leak kernel memory

sctp: COOKIE_ECHO can cause an out-of-bounds read and leak kernel memory

[Brian Geffon]

Hi,
When a listening SCTP server receives a COOKIE_ECHO chunk, sctp_unpack_cookie() is called to reconstruct the association. If HMAC is disabled ("none"), the signature check is bypassed, and the server directly processes the cached peer INIT chunk (peer_init) stored immediately after the cookie layout:

    peer_init = (struct sctp_init_chunk *)(chunk->subh.cookie_hdr + 1);

To parse the optional parameters embedded in this cached peer INIT chunk, sctp_process_init() uses the sctp_walk_params() macro. This macro blindly trusts the peer_init->chunk_hdr.length value to determine the loop boundary:

    #define sctp_walk_params(pos, chunk)\
    _sctp_walk_params((pos), (chunk), ntohs((chunk)->chunk_hdr.length))

However, the kernel does not validate that peer_init->chunk_hdr.length is actually within the physical bounds of the received COOKIE_ECHO chunk.

If an attacker injects a forged cookie where peer_init->chunk_hdr.length is inflated (e.g., 65535) while the actual payload is small, the parameter walk loop will continue out of bounds. If the walk encounters a parameter of type SCTP_PARAM_STATE_COOKIE, the switch case inside sctp_process_param() performs a memory copy directly using the unchecked parameter length:

    case SCTP_PARAM_STATE_COOKIE:
        asoc->peer.cookie_len =
            ntohs(param.p->length) - sizeof(struct sctp_paramhdr);
        kfree(asoc->peer.cookie);
        asoc->peer.cookie = kmemdup(param.cookie->body, asoc->peer.cookie_len, gfp);

If param.p->length is also inflated (e.g., 30000), kmemdup() will attempt to read up to 29,996 bytes from the sk_buff data buffer, which is limited to the actual received packet size. This triggers a KASAN slab-out-of-bounds read or can leak adjacent memory on non-KASAN builds. I do have a working reproduction of this that allows an unprivledged user to leak kernel memory, I can share it with the maintainers upon request. Because net.sctp.cookie_hmac_alg=none can be set per-namespace this is fairly easy to reproduce.

The issue was verified on Linux 7.1-rc5. KASAN detected the following slab-out-of-bounds read:
==================================================================
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x3b/0x50
Read of size 29996 at addr ffff88810fa76900 by task repro/666
CPU: 11 UID: 0 PID: 666 Comm: repro Not tainted 7.1.0-rc5-virtme #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <IRQ>
 dump_stack_lvl+0x4d/0x70
 print_report+0x153/0x4c6
 ? kmemdup_noprof+0x3b/0x50
 ? sctp_process_init+0x11f2/0x2bc0
 kasan_report+0xda/0x110
 ? kmemdup_noprof+0x3b/0x50
 kasan_check_range+0x125/0x200
 __asan_memcpy+0x23/0x60
 kmemdup_noprof+0x3b/0x50
 sctp_process_init+0x11f2/0x2bc0
 ? __pfx_sctp_process_init+0x10/0x10
 ? printk+0x9e/0xc0
 ? __pfx_printk+0x10/0x10
 ? sctp_assoc_add_peer+0x1ff/0xd20
 ? sctp_cmp_addr_exact+0x3b/0xb0
 ? sctp_assoc_add_peer+0x2a0/0xd20
 sctp_sf_do_5_1D_ce+0x585/0x1700
...