Cloudanix VulnDB

CVE-2026-68289

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in handling very large data chunks for one type of network communication can make the whole computer crash without warning.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Integer overflow in TIPC socket receive paths where min_t(int, ...) casts a size_t buffer length, allowing negative values when exceeding INT_MAX that propagate to simple_copy_to_iter and trigger WARN_ON followed by kernel panic.

Why it matters to the business

Unexpected system crashes causing denial of service on hosts running TIPC-enabled services, with potential downtime for networked applications relying on the protocol.

How an attack unfolds

An attacker supplies oversized buffers through io_uring or similar interfaces to tipc_recvmsg or tipc_recvstream, causing the length calculation to wrap negative and reach the datagram copy routine where it triggers the panic condition.

How to fix it

Apply the upstream kernel patch replacing min_t(int, ...) with min_t(size_t, ...) in tipc/socket.c for both recvmsg and recvstream functions; rebuild and deploy updated kernels to affected systems.

How to confirm the fix worked

Inspect net/tipc/socket.c to confirm min_t(size_t, dlen - offset, buflen) usage and verify absence of the original int cast pattern; test with oversized io_uring buffers to ensure no WARN_ON or panic occurs.

Typical attack path

  1. Locate systems exposing TIPC sockets
  2. Provide large size_t buffer via io_uring recvmsg path
  3. Invoke receive functions triggering min_t(int) overflow
  4. Cause negative length to reach simple_copy_to_iter and panic

How to detect it

Search kernel logs and crash dumps for stack traces containing simple_copy_to_iter, __skb_datagram_iter, skb_copy_datagram_iter, and tipc_recvmsg or tipc_recvstream; correlate with io_uring activity on TIPC sockets.

  • simple_copy_to_iter+0x9e/0xd0
  • tipc_recvmsg+0x3d7/0xe80
  • kernel: panic_on_warn set
  • min_t(int, dlen - offset, buflen)

What your security team should do

  • Apply kernel updates containing the TIPC fix as soon as available
  • Audit for TIPC protocol usage and disable where not required
  • Monitor kernel logs for panic_on_warn entries referencing tipc_recvmsg

The record

In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.

Affected packages

Ecosystem Package Introduced Fixed