CVE-2023-53517 (GCVE-0-2023-53517)
Vulnerability from cvelistv5
Published
2025-10-01 11:46
Modified
2026-08-05 09:14
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
tipc: do not update mtu if msg_max is too small in mtu negotiation
When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().
With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
tipc: Too large msg, purging xmit list 1 5 0 40 4!
tipc: Too large msg, purging xmit list 1 15 0 60 4!
And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:
general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
Call Trace:
<IRQ>
skb_release_data+0xf9/0x1d0
kfree_skb_reason+0x40/0x100
tipc_link_xmit+0x57a/0x740 [tipc]
tipc_node_xmit+0x16c/0x5c0 [tipc]
tipc_named_node_up+0x27f/0x2c0 [tipc]
tipc_node_write_unlock+0x149/0x170 [tipc]
tipc_rcv+0x608/0x740 [tipc]
tipc_udp_recv+0xdc/0x1f0 [tipc]
udp_queue_rcv_one_skb+0x33e/0x620
udp_unicast_rcv_skb.isra.72+0x75/0x90
__udp4_lib_rcv+0x56d/0xc20
ip_protocol_deliver_rcu+0x100/0x2d0
This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),
and not updating mtu if it is too small.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/tipc/link.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "2bd4ff4ffb92113f8acd04dbaed83269172c24b4",
"status": "affected",
"version": "ed193ece2649c194a87a9d8470195760d367c075",
"versionType": "git"
},
{
"lessThan": "575e84d90a74c0b091b3417ba763ebb237aa0a8c",
"status": "affected",
"version": "ed193ece2649c194a87a9d8470195760d367c075",
"versionType": "git"
},
{
"lessThan": "259683001d7e879fea4b42084fb6560dd9408a7e",
"status": "affected",
"version": "ed193ece2649c194a87a9d8470195760d367c075",
"versionType": "git"
},
{
"lessThan": "1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2",
"status": "affected",
"version": "ed193ece2649c194a87a9d8470195760d367c075",
"versionType": "git"
},
{
"lessThan": "56077b56cd3fb78e1c8619e29581ba25a5c55e86",
"status": "affected",
"version": "ed193ece2649c194a87a9d8470195760d367c075",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/tipc/link.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.1"
},
{
"lessThan": "4.1",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.113",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.30",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.3.*",
"status": "unaffected",
"version": "6.3.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.4",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.181",
"versionStartIncluding": "4.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.113",
"versionStartIncluding": "4.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.30",
"versionStartIncluding": "4.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.3.4",
"versionStartIncluding": "4.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.4",
"versionStartIncluding": "4.1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: do not update mtu if msg_max is too small in mtu negotiation\n\nWhen doing link mtu negotiation, a malicious peer may send Activate msg\nwith a very small mtu, e.g. 4 in Shuang\u0027s testing, without checking for\nthe minimum mtu, l-\u003emtu will be set to 4 in tipc_link_proto_rcv(), then\nn-\u003elinks[bearer_id].mtu is set to 4294967228, which is a overflow of\n\u00274 - INT_H_SIZE - EMSG_OVERHEAD\u0027 in tipc_link_mss().\n\nWith tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:\n\n tipc: Too large msg, purging xmit list 1 5 0 40 4!\n tipc: Too large msg, purging xmit list 1 15 0 60 4!\n\nAnd with tipc_link_entry.mtu 4294967228, a huge skb was allocated in\nnamed_distribute(), and when purging it in tipc_link_xmit(), a crash\nwas even caused:\n\n general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19\n RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0\n Call Trace:\n \u003cIRQ\u003e\n skb_release_data+0xf9/0x1d0\n kfree_skb_reason+0x40/0x100\n tipc_link_xmit+0x57a/0x740 [tipc]\n tipc_node_xmit+0x16c/0x5c0 [tipc]\n tipc_named_node_up+0x27f/0x2c0 [tipc]\n tipc_node_write_unlock+0x149/0x170 [tipc]\n tipc_rcv+0x608/0x740 [tipc]\n tipc_udp_recv+0xdc/0x1f0 [tipc]\n udp_queue_rcv_one_skb+0x33e/0x620\n udp_unicast_rcv_skb.isra.72+0x75/0x90\n __udp4_lib_rcv+0x56d/0xc20\n ip_protocol_deliver_rcu+0x100/0x2d0\n\nThis patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),\nand not updating mtu if it is too small."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:N - The vulnerable code is reached from `tipc_udp_recv()` \u2192 `tipc_rcv()` \u2192 `tipc_link_proto_rcv()`, i.e. attacker-supplied TIPC link-protocol packets arriving on the UDP bearer (default port 6118), which is routable across networks \u2014 exactly the path in the reported crash trace. TIPC UDP bearers are used for clustered/cloud deployments spanning L3 segments, so no same-segment adjacency is required.\nAC:L - The attacker deterministically controls the whole sequence: send an unauthenticated LINK_CONFIG discovery packet to create the node/link, then reply to the peer\u0027s RESET with an ACTIVATE carrying `max_pkt = 4`, and the u32 underflow plus wrapped skb allocation follow with certainty. No race, no memory-layout luck, and the only preconditions (default net_id 4711, session numbers) are attacker-supplied or default.\nPR:N - TIPC neighbour discovery and link establishment are entirely unauthenticated \u2014 `tipc_disc_rcv()` validates only net_id and address scope, and `tipc_link_validate_msg()` only checks session numbers supplied by the same attacker. CONFIG_TIPC_CRYPTO is optional and unkeyed by default, so no credentials of any kind are needed.\nUI:N - The malicious ACTIVATE message is processed in softirq context on packet receive, and the resulting `tipc_named_node_up()` bulk publication is emitted automatically when the link comes up. No local user action is involved.\nS:U - The integer underflow, undersized skb allocation, and heap overflow all occur within the kernel\u0027s own security authority on the target node. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - The wrapped `tipc_buf_acquire()` yields an skb whose `skb-\u003elen` is ~4 GiB while its backing slab object is only a few hundred bytes, and `skb-\u003edata` is placed past `skb-\u003eend`; the resulting heap corruption and oversized-length skb give an attacker leverage to read adjacent kernel heap memory. Per the memory-corruption guidance this warrants High.\nI:H - This is a genuine out-of-bounds heap write \u2014 `tipc_msg_init()`\u0027s memset and the `publ_to_item()` loop write past the undersized buffer, corrupting `skb_shared_info` and neighbouring slab objects. The attacker tunes the wrap by choosing `msg_max_pkt` in 4-byte steps, selecting the target slab cache and write offset, which is a strong primitive for control-flow hijacking.\nA:H - The commit documents a reproducible `general protection fault ... kfree_skb_list_reason` from dereferencing the corrupted skb_shared_info, plus an endless \"Too large msg, purging xmit list\" storm that wedges the link. A remote unauthenticated attacker can panic the node at will."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T09:14:33.974Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4"
},
{
"url": "https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763ebb237aa0a8c"
},
{
"url": "https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e"
},
{
"url": "https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2"
},
{
"url": "https://git.kernel.org/stable/c/56077b56cd3fb78e1c8619e29581ba25a5c55e86"
}
],
"title": "tipc: do not update mtu if msg_max is too small in mtu negotiation",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-53517",
"datePublished": "2025-10-01T11:46:04.673Z",
"dateReserved": "2025-10-01T11:39:39.406Z",
"dateUpdated": "2026-08-05T09:14:33.974Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…