IM
IronMonkey Threat Research

CVE-2026-31411 MEDIUM

Published: 2026-04-08 | Last Modified: 2026-07-25 | Status: Modified

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

Additional Descriptions (1)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: atm: corrige un fallo debido a un puntero vcc no validado en sigd_send() Reproductor disponible en [1]. La ruta de envío de ATM (sendmsg -> vcc_sendmsg -> sigd_send) lee el puntero vcc de msg -> vcc y lo usa directamente sin ninguna validación. Este puntero proviene del espacio de usuario a través de sendmsg() y puede ser forjado arbitrariamente: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // se convierte en demonio de señalización ATM struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // puntero vcc falso sendmsg(fd, &msg, 0); // el kernel desreferencia 0xdeadbeef En operación normal, el kernel envía el puntero vcc al demonio de señalización a través de sigd_enq() al procesar operaciones como connect(), bind() o listen(). Se espera que el demonio devuelva el mismo puntero al responder. Sin embargo, un demonio malicioso puede enviar valores de puntero arbitrarios. Esto se soluciona introduciendo find_get_vcc() que valida el puntero buscando en vcc_hash (similar a cómo sigd_close() itera sobre todos los VCC), y adquiere una referencia a través de sock_hold() si se encuentra. Dado que struct atm_vcc incrusta struct sock como su primer miembro, comparten la misma vida útil. Por lo tanto, usar sock_hold/sock_put es suficiente para mantener el vcc activo mientras se está utilizando. Tenga en cuenta que puede haber una condición de carrera con sigd_close() que podría marcar el vcc con varias banderas (por ejemplo, ATM_VF_RELEASED) después de que find_get_vcc() retorne. Sin embargo, sock_hold() garantiza que la memoria permanece válida, por lo que esta condición de carrera solo afecta el estado lógico, no la seguridad de la memoria. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

CVSS Metrics

Base Score: 5.5 (MEDIUM)

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack VectorLOCAL
Attack ComplexityLOW
Privileges RequiredLOW
User InteractionNONE
ScopeUNCHANGED
Confidentiality ImpactNONE
Integrity ImpactNONE
Availability ImpactHIGH

Source: [email protected]

Type: Primary

Exploitability Score: 1.8

Impact Score: 3.6

Weaknesses

Source Type Description
[email protected] Primary
en CWE-476

Affected Products

Vendor Product Version Update Type
linux linux_kernel * <built-in method update of dict object at 0x7d24246e5740> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d23beb84480> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d2461ea3d00> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d23549fffc0> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d24246e7e80> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d24246e4e80> Operating System
linux linux_kernel * <built-in method update of dict object at 0x7d23a6667700> Operating System
linux linux_kernel 2.6.12 <built-in method update of dict object at 0x7d24246e4040> Operating System
linux linux_kernel 2.6.12 <built-in method update of dict object at 0x7d23beb849c0> Operating System
linux linux_kernel 2.6.12 <built-in method update of dict object at 0x7d24246e47c0> Operating System
linux linux_kernel 2.6.12 <built-in method update of dict object at 0x7d23beb85d40> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d24246e4d80> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d23549fd8c0> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d23a52f5a40> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d24a507cbc0> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d23a66678c0> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d23a52f5080> Operating System
linux linux_kernel 7.0 <built-in method update of dict object at 0x7d242450b840> Operating System

Affected Configurations

Operator: OR

Vulnerable CPE
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:2.6.12:rc2:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:2.6.12:rc3:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:2.6.12:rc4:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:2.6.12:rc5:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
Yes cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*

References

Notification
Message here