FKIE_CVE-2026-31411
Vulnerability from fkie_nvd - Published: 2026-04-08 14:16 - Updated: 2026-04-08 21:26
Severity ?
Summary
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
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix crash due to unvalidated vcc pointer in sigd_send()\n\nReproducer available at [1].\n\nThe ATM send path (sendmsg -\u003e vcc_sendmsg -\u003e sigd_send) reads the vcc\npointer from msg-\u003evcc and uses it directly without any validation. This\npointer comes from userspace via sendmsg() and can be arbitrarily forged:\n\n int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0);\n ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon\n struct msghdr msg = { .msg_iov = \u0026iov, ... };\n *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer\n sendmsg(fd, \u0026msg, 0); // kernel dereferences 0xdeadbeef\n\nIn normal operation, the kernel sends the vcc pointer to the signaling\ndaemon via sigd_enq() when processing operations like connect(), bind(),\nor listen(). The daemon is expected to return the same pointer when\nresponding. However, a malicious daemon can send arbitrary pointer values.\n\nFix this by introducing find_get_vcc() which validates the pointer by\nsearching through vcc_hash (similar to how sigd_close() iterates over\nall VCCs), and acquires a reference via sock_hold() if found.\n\nSince struct atm_vcc embeds struct sock as its first member, they share\nthe same lifetime. Therefore using sock_hold/sock_put is sufficient to\nkeep the vcc alive while it is being used.\n\nNote that there may be a race with sigd_close() which could mark the vcc\nwith various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns.\nHowever, sock_hold() guarantees the memory remains valid, so this race\nonly affects the logical state, not memory safety.\n\n[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3"
}
],
"id": "CVE-2026-31411",
"lastModified": "2026-04-08T21:26:13.410",
"metrics": {},
"published": "2026-04-08T14:16:27.977",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1c8bda3df028d5e54134077dcd09f46ca8cfceb5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/21c303fec138c002f90ed33bce60e807d53072bb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3e1a8b00095246a9a2b46b57f6d471c6d3c00ed2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/440c9a5fc477a8ee259d8bf669531250b8398651"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/69d3f9ee5489e6e8b66defcfa226e91d82393297"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ae88a5d2f29b69819dc7b04086734439d074a643"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c96549d07dfdd51aadf0722cfb40711574424840"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e3f80666c2739296c3b69a127300455c43aa1067"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…