FKIE_CVE-2026-98548
Vulnerability from fkie_nvd - Published: 2026-10-18 16:17 - Updated: 2026-10-24 14:16
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
sctp: discard the rest of the packet on a stale-cookie error
When an association is in COOKIE-ECHOED state and the peer sends a
bundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary
addresses, processing the ERROR chunk takes the non-fatal stale-cookie
retry path sctp_sf_do_5_2_6_stale(), which queues
SCTP_CMD_DEL_NON_PRIMARY while keeping the association alive.
sctp_cmd_del_non_primary() removes every non-primary transport -
including the very transport this packet arrived on, which is still
referenced by the receive lookup and shared by all chunks of the
packet via chunk->transport.
sctp_assoc_rm_peer() does redirect asoc->peer.last_data_from away from
the removed transport, but right afterwards the bundled DATA chunk
makes sctp_assoc_bh_rcv() re-register
asoc->peer.last_data_from = chunk->transport unconditionally, undoing
the redirection with the just-removed transport.
Once the packet is done, the receive reference is dropped and the
transport is RCU-freed, while the surviving association keeps the
dangling last_data_from. A later FWD-TSN (or the delayed SACK timer)
makes sctp_gen_sack() dereference it (->param_flags and friends), and
sctp_make_sack()/sctp_outq_select_transport() may write to the freed
object and link it into the live transport list. This is a
use-after-free triggerable by any malicious SCTP peer (or a local
unprivileged user acting as one) with no capabilities required:
BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660
Read of size 4 at addr ffff88800e1e356c by task poc/115
Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <-
sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv
Allocated: sctp_transport_new <- sctp_assoc_add_peer <-
sctp_process_init (INIT-ACK processing)
Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core
(call_rcu queued by sctp_transport_put at end of sctp_rcv)
The buggy address is located 364 bytes inside of freed 1024-byte
region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k
Note that commit 03a9d10ecf71 ("sctp: drop a chunk if its transport
was removed") only covers the window between the receive lookup and
the chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog);
here the transport is removed *while* the packet is being processed,
by an earlier chunk of the same packet, so the drop in sctp_inq_push()
does not reach this path. Verified with the bundled [ERROR(Stale
Cookie)][DATA] + FWD-TSN reproducer: the KASAN report above still
fires with that commit applied, and is gone with this patch on top.
Fix it by discarding the rest of the packet on this path, as suggested
by Xin. After the stale-cookie ERROR has sent the association back to
COOKIE-WAIT and removed the non-primary transports, the remaining
chunks of the packet can only run against the restarted handshake
while referencing the removed arrival transport through
chunk->transport: besides the last_data_from registration above,
sctp_cmd_setup_t2() and the sctp_make_*() reply builders would also
copy that pointer into association-lifetime state that
sctp_assoc_rm_peer() has already sanitized. Let the peer retransmit
them, in line with what sctp_inq_push() does for chunks whose
transport was removed before processing.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/sctp/sm_statefuns.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "854c053c71459f8db7ef07db9cfa4eec5f5206f2",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "965e21ea16acb394d5e5801998ca9b0adc669665",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1cd246b214dc9acf4e2f11d58c035e1e672fe7d2",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "d68c9287b3ca0d6faadc61fbcb18d1a6b5493321",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "ec23855274a73906b02f0d124fefd9cb3c008b1d",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "6df536c5acbc0abd6f119d02e24f4a2ed97707f4",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4498467a8af06cfa3d71cb04bd7c4170dec8f449",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/sctp/sm_statefuns.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.271",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.189",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.112",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: discard the rest of the packet on a stale-cookie error\n\nWhen an association is in COOKIE-ECHOED state and the peer sends a\nbundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary\naddresses, processing the ERROR chunk takes the non-fatal stale-cookie\nretry path sctp_sf_do_5_2_6_stale(), which queues\nSCTP_CMD_DEL_NON_PRIMARY while keeping the association alive.\nsctp_cmd_del_non_primary() removes every non-primary transport -\nincluding the very transport this packet arrived on, which is still\nreferenced by the receive lookup and shared by all chunks of the\npacket via chunk-\u003etransport.\n\nsctp_assoc_rm_peer() does redirect asoc-\u003epeer.last_data_from away from\nthe removed transport, but right afterwards the bundled DATA chunk\nmakes sctp_assoc_bh_rcv() re-register\nasoc-\u003epeer.last_data_from = chunk-\u003etransport unconditionally, undoing\nthe redirection with the just-removed transport.\n\nOnce the packet is done, the receive reference is dropped and the\ntransport is RCU-freed, while the surviving association keeps the\ndangling last_data_from. A later FWD-TSN (or the delayed SACK timer)\nmakes sctp_gen_sack() dereference it (-\u003eparam_flags and friends), and\nsctp_make_sack()/sctp_outq_select_transport() may write to the freed\nobject and link it into the live transport list. This is a\nuse-after-free triggerable by any malicious SCTP peer (or a local\nunprivileged user acting as one) with no capabilities required:\n\n BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660\n Read of size 4 at addr ffff88800e1e356c by task poc/115\n Call Trace: sctp_do_sm \u003c- sctp_assoc_bh_rcv \u003c- sctp_inq_push \u003c-\n sctp_rcv \u003c- ip_protocol_deliver_rcu \u003c- ip_rcv\n Allocated: sctp_transport_new \u003c- sctp_assoc_add_peer \u003c-\n sctp_process_init (INIT-ACK processing)\n Freed: kfree \u003c- sctp_transport_destroy_rcu \u003c- rcu_core\n (call_rcu queued by sctp_transport_put at end of sctp_rcv)\n The buggy address is located 364 bytes inside of freed 1024-byte\n region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k\n\nNote that commit 03a9d10ecf71 (\"sctp: drop a chunk if its transport\nwas removed\") only covers the window between the receive lookup and\nthe chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog);\nhere the transport is removed *while* the packet is being processed,\nby an earlier chunk of the same packet, so the drop in sctp_inq_push()\ndoes not reach this path. Verified with the bundled [ERROR(Stale\nCookie)][DATA] + FWD-TSN reproducer: the KASAN report above still\nfires with that commit applied, and is gone with this patch on top.\n\nFix it by discarding the rest of the packet on this path, as suggested\nby Xin. After the stale-cookie ERROR has sent the association back to\nCOOKIE-WAIT and removed the non-primary transports, the remaining\nchunks of the packet can only run against the restarted handshake\nwhile referencing the removed arrival transport through\nchunk-\u003etransport: besides the last_data_from registration above,\nsctp_cmd_setup_t2() and the sctp_make_*() reply builders would also\ncopy that pointer into association-lifetime state that\nsctp_assoc_rm_peer() has already sanitized. Let the peer retransmit\nthem, in line with what sctp_inq_push() does for chunks whose\ntransport was removed before processing."
}
],
"id": "CVE-2026-98548",
"lastModified": "2026-10-24T14:16:46.943",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-10-18T16:17:06.767",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1cd246b214dc9acf4e2f11d58c035e1e672fe7d2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4498467a8af06cfa3d71cb04bd7c4170dec8f449"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6df536c5acbc0abd6f119d02e24f4a2ed97707f4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/854c053c71459f8db7ef07db9cfa4eec5f5206f2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/965e21ea16acb394d5e5801998ca9b0adc669665"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d68c9287b3ca0d6faadc61fbcb18d1a6b5493321"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ec23855274a73906b02f0d124fefd9cb3c008b1d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.