CVE-2025-39828 — atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().

Affected: Linux, Siemens SIMATIC CN 4100

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

atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().

syzbot reported the splat below. [0]

When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.

The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.

The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.

struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN;

typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;

The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().

atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:

1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()

The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.

Let's add a new ->pre_send() hook to validate messages from sendmsg().

[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gb…

Most recent entries from all

CVE-2025-39828 — atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().