---
id: CVE-2026-68315
title: 'sctp: validate stream count in sctp_process_strreset_inreq()'
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  sctp: validate stream count in sctp_process_strreset_inreq()

  When processing a RESET_IN_REQUEST from a peer,
  sctp_process_strreset_inreq() derives the stream count fro…
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    61327d8e7cfb0259d527be17202630f556213249
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    7cf7439948e3bf639119119922c88ec190874ca3
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    60c47dea5d320d2fc706e9aad1db38a04df0a056
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    6f0e39d180cd7cced647381b6fa14fd83d261047
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    1a10fe1aa9c01f41b389a31906a77d538637c9d9
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    00ae679cb21a035491fdad8d58dc6d79cc68b675
  - >-
    Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <
    18ae07691d43183d270de8be9dc8e027906015d9
  - Linux 4.11
ssvc:
  exploitation: none
  automatable: 'yes'
  technicalImpact: partial
  timestamp: '2026-10-16T15:47:00.535274Z'
published: '2026-08-10'
updated: '2026-10-16'
sourceUpdated: '2026-10-16T15:53:07.723Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-68315'
references:
  - url: 'https://git.kernel.org/stable/c/61327d8e7cfb0259d527be17202630f556213249'
  - url: 'https://git.kernel.org/stable/c/7cf7439948e3bf639119119922c88ec190874ca3'
  - url: 'https://git.kernel.org/stable/c/60c47dea5d320d2fc706e9aad1db38a04df0a056'
  - url: 'https://git.kernel.org/stable/c/b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b'
  - url: 'https://git.kernel.org/stable/c/6f0e39d180cd7cced647381b6fa14fd83d261047'
  - url: 'https://git.kernel.org/stable/c/1a10fe1aa9c01f41b389a31906a77d538637c9d9'
  - url: 'https://git.kernel.org/stable/c/00ae679cb21a035491fdad8d58dc6d79cc68b675'
  - url: 'https://git.kernel.org/stable/c/18ae07691d43183d270de8be9dc8e027906015d9'
tags:
  - cve.org
epss: 0.00512
epssPercentile: 0.42333
ingestedAt: '2026-10-16T17:24:46.857Z'
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

sctp: validate stream count in sctp_process_strreset_inreq()

When processing a RESET_IN_REQUEST from a peer,
sctp_process_strreset_inreq() derives the stream count from the
parameter length but does not check whether the resulting
RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.

The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes
larger than the IN request header (sctp_strreset_inreq, 8 bytes).
Generally, the IP payload is bounded to 65535 bytes, so the stream
list cannot be large enough to trigger the overflow. However, on
interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a
stream list that fits within the incoming IN parameter can cause a
__u16 overflow in sctp_make_strreset_req() when computing the OUT
request size, leading to an undersized skb allocation and a kernel
BUG:

  net/core/skbuff.c:207         skb_panic
  net/core/skbuff.c:2625        skb_put
  net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk
  net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req
  net/sctp/stream.c:655         sctp_process_strreset_inreq

The local setsockopt path validates the generated reset request size.
However, for an incoming-only reset, it accounts for the smaller IN
request even though the peer must generate an OUT request with the same
stream list. Such a request cannot be completed successfully by the
peer.

Reject peer IN requests whose corresponding OUT request would exceed
SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an
IN request that would require an oversized OUT request from the peer.

## Affected

- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 61327d8e7cfb0259d527be17202630f556213249`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 7cf7439948e3bf639119119922c88ec190874ca3`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 60c47dea5d320d2fc706e9aad1db38a04df0a056`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 6f0e39d180cd7cced647381b6fa14fd83d261047`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 1a10fe1aa9c01f41b389a31906a77d538637c9d9`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 00ae679cb21a035491fdad8d58dc6d79cc68b675`
- `Linux >= 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 < 18ae07691d43183d270de8be9dc8e027906015d9`
- `Linux 4.11`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.