GHSA-9Q92-J4JR-J3JP

Vulnerability from github – Published: 2026-04-08 15:31 – Updated: 2026-04-08 15:31
VLAI?
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-31411"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T14:16:27Z",
    "severity": null
  },
  "details": "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": "GHSA-9q92-j4jr-j3jp",
  "modified": "2026-04-08T15:31:44Z",
  "published": "2026-04-08T15:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31411"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c8bda3df028d5e54134077dcd09f46ca8cfceb5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/21c303fec138c002f90ed33bce60e807d53072bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e1a8b00095246a9a2b46b57f6d471c6d3c00ed2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/440c9a5fc477a8ee259d8bf669531250b8398651"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/69d3f9ee5489e6e8b66defcfa226e91d82393297"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae88a5d2f29b69819dc7b04086734439d074a643"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c96549d07dfdd51aadf0722cfb40711574424840"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e3f80666c2739296c3b69a127300455c43aa1067"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.