In the Linux kernel, the following vulnerability has been resolved:
sctp: fix OOB write to userspace in sctpgetsockoptpeerauthchunks
sctpgetsockoptpeerauthchunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with
if (len < num_chunks)
return -EINVAL;
but then writes numchunks bytes to p->gauthchunks, which lives at offset offsetof(struct sctpauthchunks, gauthchunks) == 8 inside optval. The check is missing the sizeof(struct sctpauthchunks) = 8-byte header. When the caller supplies len == numchunks (for any numchunks > 0) the test passes but copytouser() writes sizeof(struct sctpauthchunks) = 8 bytes past the declared buffer.
The sibling function sctpgetsockoptlocalauthchunks() at the next line already has the correct check:
if (len < sizeof(struct sctp_authchunks) + num_chunks)
return -EINVAL;
Align the peer variant with its sibling.
Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries numchunks with a short optval, then issues the real getsockopt with len == numchunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53004.json",
"cna_assigner": "Linux"
}