VYPR
Medium severity5.5NVD Advisory· Published Apr 8, 2026· Updated May 20, 2026

CVE-2026-31411

CVE-2026-31411

Description

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.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A missing vcc pointer validation in the Linux kernel's ATM subsystem allows a local, privileged attacker to crash the system via crafted sendmsg() calls.

The Linux kernel's ATM (Asynchronous Transfer Mode) networking subsystem contains a use of an unvalidated pointer in the sigd_send() function. In the ATM send path (sendmsg -> vcc_sendmsg -> sigd_send), the kernel reads a virtual circuit connection (vcc) pointer directly from the msg structure passed from userspace without any validation. This pointer can be arbitrarily forged by a user who has obtained the privileged signaling daemon role via the ATMSIGD_CTRL ioctl, allowing them to supply a fake pointer (e.g., 0xdeadbeef) that the kernel subsequently dereferences [1].

To exploit this vulnerability, an attacker must first gain the ability to act as the ATM signaling daemon, which is achieved by opening an AF_ATMSVC socket and issuing the ATMSIGD_CTRL ioctl. Once in this privileged role, the attacker can craft a sendmsg() call with a msghdr structure containing a fabricated vcc pointer. The kernel does not verify that this pointer corresponds to an actual, allocated VCC before dereferencing it, leading to a crash when an invalid address is accessed [1].

The impact is limited to a denial of service (system crash) due to a kernel NULL pointer dereference or access to invalid memory. The CVSS v3 score of 5.5 (Medium) reflects this availability impact, with an attack vector that requires local access and high privileges (the attacker must already be able to control the signaling daemon role). No privilege escalation or data confidentiality breach is involved [1].

The fix, introduced in the Linux kernel commit series, adds a find_get_vcc() function that validates the vcc pointer by searching through vcc_hash (the global hash table of active VCCs) and acquiring a reference via sock_hold(). This ensures that only valid, allocated VCCs are used and that the memory remains valid while in use. The fix also notes a potential race condition with sigd_close(), but sock_hold() guarantees memory safety even in that scenario [1]. The security fix is included in upstream Linux kernel releases; users should apply the latest stable updates to mitigate this vulnerability.

AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

0

No patches discovered yet.

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

8

News mentions

0

No linked articles in our index yet.