Common Weakness Enumeration

CWE-401

Allowed

Missing Release of Memory after Effective Lifetime

Abstraction: Variant · Status: Draft

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

2002 vulnerabilities reference this CWE, most recent first.

GHSA-VX69-74F2-J536

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-08-16 00:00
VLAI
Details

Several memory leaks were found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU in versions up to and including 6.0. They exist in contrib/vhost-user-gpu/vhost-user-gpu.c and contrib/vhost-user-gpu/virgl.c due to improper release of memory (i.e., free) after effective lifetime.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-3544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Several memory leaks were found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU in versions up to and including 6.0. They exist in contrib/vhost-user-gpu/vhost-user-gpu.c and contrib/vhost-user-gpu/virgl.c due to improper release of memory (i.e., free) after effective lifetime.",
  "id": "GHSA-vx69-74f2-j536",
  "modified": "2022-08-16T00:00:42Z",
  "published": "2022-05-24T19:03:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3544"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1958935"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-27"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210720-0008"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4980"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/05/31/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXF7-8458-RQ8X

Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-07 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net: mhi: Fix memory leak in mhi_net_dellink()

MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak.

This patch calls free_netdev() to fix it since netdev_priv is used after unregister.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mhi: Fix memory leak in mhi_net_dellink()\n\nMHI driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch calls free_netdev() to fix it since netdev_priv\nis used after unregister.",
  "id": "GHSA-vxf7-8458-rq8x",
  "modified": "2025-11-07T21:31:19Z",
  "published": "2025-05-01T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49817"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25a270343b0f16e1f6e65f541a15975a35e238ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88da008e5e2f9753726ea5a51ef2eb144e9de927"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7c125bd79f50ec6094761090be81d02726ec6f4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXJ7-P6GH-99VG

Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-14 21:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Fix a memory leak with reused mmap_offset

drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked.

Call drm_vma_node_allow_once() instead to prevent that memory leak.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T17:15:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix a memory leak with reused mmap_offset\n\ndrm_vma_node_allow() and drm_vma_node_revoke() should be called in\nbalanced pairs. We call drm_vma_node_allow() once per-file everytime a\nuser calls mmap_offset, but only call drm_vma_node_revoke once per-file\non each mmap_offset. As the mmap_offset is reused by the client, the\nper-file vm_count may remain non-zero and the rbtree leaked.\n\nCall drm_vma_node_allow_once() instead to prevent that memory leak.",
  "id": "GHSA-vxj7-p6gh-99vg",
  "modified": "2025-04-14T21:32:23Z",
  "published": "2025-03-27T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53002"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0220e4fe178c3390eb0291cdb34912d66972db8a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W24W-WP77-QFFM

Vulnerability from github – Published: 2023-07-05 21:34 – Updated: 2023-07-05 21:34
VLAI
Summary
CometBFT may duplicate transactions in the mempool's data structures
Details

Impact

The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list.

Unfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node.

These are the steps to cause the above duplication problem. Everything should happen within one height, that is no FinalizeBlock or BeginBlock ABCI calls should happen while these steps are reproduced:

  1. send transaction tx1 to the target full node via RPC
  2. send N more different transactions to the target full node, where N should be higher than the node's configured value for cache_size in config.toml
  3. send transaction tx1 again to the target full node

One of the copies of tx1 is now stuck in the mempool's data structures. Effectively causing a memory leak, and having that node gossiping that transaction to its peers forever.

The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node.

This problem is present in releases: v0.37.0, and v0.37.1, as well as in v0.34.28, and all previous releases of the CometBFT repo. It will be fixed in releases v0.34.29 and v0.37.2.

Patches

The PR containing the fix is here.

Workarounds

  • Increasing the value of cache_size in config.toml makes it very difficult to effectively attack a full node.
  • Not exposing the transaction submission RPC's would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.

References

  • PR that introduced the map to track transactions in the mempool.
  • PR containing the fix.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cometbft/cometbft"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.34.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cometbft/cometbft"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.37.0"
            },
            {
              "fixed": "0.37.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-34451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-05T21:34:45Z",
    "nvd_published_at": "2023-07-03T17:15:09Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe mempool maintains two data structures to keep track of outstanding transactions: a list and a map.\nThese two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. \n\nUnfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction.\nBecause the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list.\nThis happens  even if the duplicated transaction is later committed in a block.\nThe only way to remove the transaction is by restarting the node.\n\nThese are the steps to cause the above duplication problem. Everything should happen within one height, that is no `FinalizeBlock` or `BeginBlock` ABCI calls should happen while these steps are reproduced:\n\n1. send transaction tx1 to the target full node via RPC\n2. send N more different transactions to the target full node, where N should be higher than the node\u0027s configured value for `cache_size` in `config.toml`\n3. send transaction tx1 again to the target full node\n\nOne of the copies of tx1 is now _stuck_ in the mempool\u0027s data structures. Effectively causing a memory leak, and having that node gossiping that transaction to its peers forever.\n\nThe above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node.\n\nThis problem is present in releases: `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo. It will be fixed in releases `v0.34.29` and `v0.37.2`.\n\n### Patches\n\nThe PR containing the fix is [here](https://github.com/cometbft/cometbft/pull/890).\n\n\n### Workarounds\n\n* Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node.\n* Not exposing the transaction submission RPC\u0027s would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.\n\n### References\n\n* [PR](https://github.com/tendermint/tendermint/pull/2778) that introduced the map to track transactions in the mempool.\n* [PR](https://github.com/cometbft/cometbft/pull/890) containing the fix.\n",
  "id": "GHSA-w24w-wp77-qffm",
  "modified": "2023-07-05T21:34:45Z",
  "published": "2023-07-05T21:34:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cometbft/cometbft/pull/890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tendermint/tendermint/pull/2778"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cometbft/cometbft"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CometBFT may duplicate transactions in the mempool\u0027s data structures"
}

GHSA-W279-MJ9J-W893

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-19 15:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-46065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:27Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.",
  "id": "GHSA-w279-mj9j-w893",
  "modified": "2026-06-19T15:33:13Z",
  "published": "2026-05-27T15:33:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25c2b77bc463f29ee71a54b883548baf9386a0db"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a40f8bc9bb713329f1c35ffc199ee961a7135b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b53d3a52e8e5403a4f4fb57ac6cad3fd2cb1066"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4aab89603b637a2e441b38808c4f6fe7d1184df6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4fda0d6b45faad44926dd3e4f55f118d899b2e27"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ded47ad003f09a94b6a710b5c47f4aa5ceb7429"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0aafb421dd15e935d81543152617f2742cefa70"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W299-FQ8V-QVG7

Vulnerability from github – Published: 2026-01-27 12:31 – Updated: 2026-01-27 12:31
VLAI
Details

Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T10:15:49Z",
    "severity": "HIGH"
  },
  "details": "Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4.",
  "id": "GHSA-w299-fq8v-qvg7",
  "modified": "2026-01-27T12:31:18Z",
  "published": "2026-01-27T12:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24828"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Is-Daouda/is-Engine/pull/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W29X-26QV-FMMQ

Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-14 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node

When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T14:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node\n\nWhen ida_alloc_max fails, resources allocated before should be freed,\nincluding *res allocated by kmalloc and ttm_resource_init.",
  "id": "GHSA-w29x-26qv-fmmq",
  "modified": "2025-01-14T15:30:49Z",
  "published": "2024-05-17T15:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52662"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2F8-JF7V-2CJ4

Vulnerability from github – Published: 2022-08-24 00:00 – Updated: 2022-08-28 00:00
VLAI
Details

A memory leak was found in Open vSwitch (OVS) during userspace IP fragmentation processing. An attacker could use this flaw to potentially exhaust available memory by keeping sending packet fragments.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-3905"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A memory leak was found in Open vSwitch (OVS) during userspace IP fragmentation processing. An attacker could use this flaw to potentially exhaust available memory by keeping sending packet fragments.",
  "id": "GHSA-w2f8-jf7v-2cj4",
  "modified": "2022-08-28T00:00:32Z",
  "published": "2022-08-24T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3905"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openvswitch/ovs-issues/issues/226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openvswitch/ovs/commit/803ed12e31b0377c37d7aa8c94b3b92f2081e349"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3905"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2019692"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202311-16"
    },
    {
      "type": "WEB",
      "url": "https://ubuntu.com/security/CVE-2021-3905"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2RG-V998-6982

Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18
VLAI
Details

A remote user can create a specially crafted M3U file, media playlist file that when loaded by the target user, will trigger a memory leak, whereby Amarok 2.8.0 continue to waste resources over time, eventually allows attackers to cause a denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-13152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-20T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A remote user can create a specially crafted M3U file, media playlist file that when loaded by the target user, will trigger a memory leak, whereby Amarok 2.8.0 continue to waste resources over time, eventually allows attackers to cause a denial of service.",
  "id": "GHSA-w2rg-v998-6982",
  "modified": "2022-05-24T17:18:11Z",
  "published": "2022-05-24T17:18:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13152"
    },
    {
      "type": "WEB",
      "url": "https://r00texpl0it.wordpress.com/2020/05/20/kde-amarok-2-8-0-allows-remote-attackers-to-cause-a-denial-of-service"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/159898/Amarok-2.8.0-Denial-Of-Service.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2X4-6HP6-4HC7

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-15 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open

ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid().

Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked.

Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks.

Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open\n\nksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount\nincremented via ksmbd_fp_get(). parse_durable_handle_context() in\nthe DURABLE_REQ_V2 case properly releases this reference on every\npath inside the ClientGUID-match branch, either by calling\nksmbd_put_durable_fd() or by transferring ownership to dh_info-\u003efp\nfor a successful reconnect. However, when an entry exists in the\nglobal file table with the same CreateGuid but a different\nClientGUID, the code simply falls through to the new-open path\nwithout dropping the reference obtained from ksmbd_lookup_fd_cguid().\n\nPer MS-SMB2 section 3.3.5.9.10 (\"Handling the\nSMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context\"), the server\nMUST locate an Open whose Open.CreateGuid matches the request\u0027s\nCreateGuid AND whose Open.ClientGuid matches the ClientGuid of the\nconnection that received the request. If no such Open is found, the\nserver MUST continue with the normal open execution phase. A\nCreateGuid hit with a ClientGUID mismatch is therefore the\n\"Open not found\" case: proceeding with a new open is correct, but\nthe reference obtained purely as a side effect of the lookup must\nnot be leaked.\n\nRepeated requests that hit this mismatch pin global_ft entries,\nprevent __ksmbd_close_fd() from ever running for the corresponding\nfiles, and defeat the durable scavenger, leading to long-lived\nresource leaks.\n\nRelease the reference in the mismatch path and clear dh_info-\u003efp so\nsubsequent logic does not mistake a non-matching lookup result for\na reconnect target.",
  "id": "GHSA-w2x4-6hp6-4hc7",
  "modified": "2026-07-15T15:32:43Z",
  "published": "2026-06-24T18:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52996"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/06f709d0e531f3e54d88665dd426be3998a774e6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/407b6e699ba8b45b72cc265eed8a1bc8a7191609"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/804054d19886ac6628883d82410f6ee42a818664"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8c4a0ef19c8264c150833131af34541495832cd0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f31beef633fbf2b5af7805fa187a10bcff1d4b49"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-41
Implementation

Strategy: Libraries or Frameworks

  • Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
  • For example, glibc in Linux provides protection against free of invalid pointers.
  • When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
  • To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
Mitigation
Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Mitigation
Architecture and Design Build and Compilation

Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.

No CAPEC attack patterns related to this CWE.