Cloudanix VulnDB

CVE-2023-53517

Medium · 5.5

CVSS

5.5

EPSS

0.3%

Published

Oct 1, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's TIPC communication code can let a local user send specially crafted messages that crash the entire system.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

In TIPC link MTU negotiation, a malicious peer can supply an Activate message with an MTU below the minimum, bypassing validation in tipc_link_proto_rcv() and causing an integer underflow/overflow when computing mss in tipc_link_mss(); this leads to either repeated warning spam and message purging or allocation of an enormous skb that triggers a general protection fault during kfree_skb_list_reason in tipc_link_xmit.

Why it matters to the business

Systems using the TIPC protocol over UDP or other bearers can experience repeated kernel warnings, message loss, or full system crashes resulting in denial of service and operational downtime; the issue affects many Debian releases and upstream kernels still in use.

How an attack unfolds

An attacker with the ability to send TIPC protocol messages (local or over a UDP bearer) crafts an Activate message containing an extremely small MTU value; tipc_link_proto_rcv accepts it without checking tipc_bearer_min_mtu, stores the invalid value, and subsequent named_distribute or tipc_node_xmit paths allocate or free malformed skbs, crashing the kernel.

How to fix it

Upgrade the Linux kernel to a version containing commit 2bd4ff4ffb92113f8acd04dbaed83269172c24b4 or the Debian package versions listed as fixed (5.10.46-1 and later); if TIPC is not required, disable the module or block its UDP ports.

How to confirm the fix worked

Confirm the running kernel contains the min-MTU check in tipc_link_proto_rcv; verify package version against the fixed Debian or GIT revisions; test by attempting MTU negotiation with a deliberately undersized value and confirming the update is rejected.

Typical attack path

  1. Establish TIPC bearer connectivity (UDP or other) to the target
  2. Send crafted TIPC Activate message containing an MTU smaller than the minimum
  3. Trigger tipc_link_proto_rcv to store the underflowed MTU value
  4. Force traffic that invokes tipc_link_xmit or named_distribute to trigger the overflowed skb allocation or purge path
  5. Cause kernel panic via kfree_skb_list_reason or similar skb handling code

How to detect it

Search kernel logs and dmesg for repeated "tipc: Too large msg, purging xmit list" messages; inspect crash dumps for RIP in kfree_skb_list_reason called from tipc_link_xmit with TIPC stack frames; correlate with UDP traffic on TIPC ports preceding the fault.

  • tipc: Too large msg, purging xmit list
  • kfree_skb_list_reason+0x7e/0x1f0
  • tipc_link_xmit+0x57a/0x740 [tipc]
  • general protection fault.*0x2100001011000dd

What your security team should do

  • Prioritize kernel package updates on all systems exposing TIPC bearers
  • Disable the tipc module or filter its traffic if the protocol is unused
  • Monitor kernel logs for TIPC MTU-related warnings until patches are applied
  • Review network segmentation for any UDP ports used by TIPC

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 4.1.0 5.10.181

Related vulnerabilities