PT-2026-31306 · Linux · Linux

Published

2026-04-08

·

Updated

2026-04-08

·

CVE-2026-31411

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net: atm: fix crash due to unvalidated vcc pointer in sigd send()
Reproducer available at 1.
The ATM send path (sendmsg -> vcc sendmsg -> sigd send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:
int fd = socket(AF ATMSVC, SOCK DGRAM, 0); ioctl(fd, ATMSIGD CTRL); // become ATM signaling daemon struct msghdr msg = { .msg iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef
In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.
Fix this by introducing find get vcc() which validates the pointer by searching through vcc hash (similar to how sigd close() iterates over all VCCs), and acquires a reference via sock hold() if found.
Since struct atm vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock hold/sock put is sufficient to keep the vcc alive while it is being used.
Note that there may be a race with sigd close() which could mark the vcc with various flags (e.g., ATM VF RELEASED) after find get vcc() returns. However, sock hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

Related Identifiers

CVE-2026-31411

Affected Products

Linux