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-25RF-28XV-W8H2

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 21:30
VLAI
Details

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

drm/bridge: samsung-dsim: Fix memory leak in error path

In samsung_dsim_host_attach(), drm_bridge_add() is called to add the bridge. However, if samsung_dsim_register_te_irq() or pdata->host_ops->attach() fails afterwards, the function returns without removing the bridge, causing a memory leak.

Fix this by adding proper error handling with goto labels to ensure drm_bridge_remove() is called in all error paths. Also ensure that samsung_dsim_unregister_te_irq() is called if the attach operation fails after the TE IRQ has been registered.

samsung_dsim_unregister_te_irq() function is moved without changes to be before samsung_dsim_host_attach() to avoid forward declaration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-43397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T15:16:51Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/bridge: samsung-dsim: Fix memory leak in error path\n\nIn samsung_dsim_host_attach(), drm_bridge_add() is called to add the\nbridge. However, if samsung_dsim_register_te_irq() or\npdata-\u003ehost_ops-\u003eattach() fails afterwards, the function returns\nwithout removing the bridge, causing a memory leak.\n\nFix this by adding proper error handling with goto labels to ensure\ndrm_bridge_remove() is called in all error paths. Also ensure that\nsamsung_dsim_unregister_te_irq() is called if the attach operation\nfails after the TE IRQ has been registered.\n\nsamsung_dsim_unregister_te_irq() function is moved without changes\nto be before samsung_dsim_host_attach() to avoid forward declaration.",
  "id": "GHSA-25rf-28xv-w8h2",
  "modified": "2026-05-21T21:30:29Z",
  "published": "2026-05-08T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43397"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b07f7d2c5a4078c2f1c11bb36685084fe4e5c95"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/803ec1faf7c1823e6e3b1f2aaa81be18528c9436"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/98310fe3a2a79671b739a5344c1a11d74c503e25"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a40b92fb4b26d4cb1b5e439e55a56db7e79a82d1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e6d779654cda63d632bd8dfcdcabd125057e30a5"
    }
  ],
  "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-25V2-V763-X228

Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30
VLAI
Details

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

io_uring/sqpoll: work around a potential audit memory leak

kmemleak complains that there's a memory leak related to connect handling:

unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20

which can can happen if:

1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit().

Work around this by issuing a blanket NOP operation before the SQPOLL does anything.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:21Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/sqpoll: work around a potential audit memory leak\n\nkmemleak complains that there\u0027s a memory leak related to connect\nhandling:\n\nunreferenced object 0xffff0001093bdf00 (size 128):\ncomm \"iou-sqp-455\", pid 457, jiffies 4294894164\nhex dump (first 32 bytes):\n02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00  ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nbacktrace (crc 2e481b1a):\n[\u003c00000000c0a26af4\u003e] kmemleak_alloc+0x30/0x38\n[\u003c000000009c30bb45\u003e] kmalloc_trace+0x228/0x358\n[\u003c000000009da9d39f\u003e] __audit_sockaddr+0xd0/0x138\n[\u003c0000000089a93e34\u003e] move_addr_to_kernel+0x1a0/0x1f8\n[\u003c000000000b4e80e6\u003e] io_connect_prep+0x1ec/0x2d4\n[\u003c00000000abfbcd99\u003e] io_submit_sqes+0x588/0x1e48\n[\u003c00000000e7c25e07\u003e] io_sq_thread+0x8a4/0x10e4\n[\u003c00000000d999b491\u003e] ret_from_fork+0x10/0x20\n\nwhich can can happen if:\n\n1) The command type does something on the prep side that triggers an\n   audit call.\n2) The thread hasn\u0027t done any operations before this that triggered\n   an audit call inside -\u003eissue(), where we have audit_uring_entry()\n   and audit_uring_exit().\n\nWork around this by issuing a blanket NOP operation before the SQPOLL\ndoes anything.",
  "id": "GHSA-25v2-v763-x228",
  "modified": "2025-11-04T00:30:57Z",
  "published": "2024-07-12T15:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41001"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "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-262G-44PP-38C2

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

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

net: dsa: Fix possible memory leaks in dsa_loop_init()

kmemleak reported memory leaks in dsa_loop_init():

kmemleak: 12 new suspected memory leaks

unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ...

There are two reasons for memleak in dsa_loop_init().

First, fixed_phy_register() create and register phy_device:

fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove()

But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked.

Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs.

Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: Fix possible memory leaks in dsa_loop_init()\n\nkmemleak reported memory leaks in dsa_loop_init():\n\nkmemleak: 12 new suspected memory leaks\n\nunreferenced object 0xffff8880138ce000 (size 2048):\n  comm \"modprobe\", pid 390, jiffies 4295040478 (age 238.976s)\n  backtrace:\n    [\u003c000000006a94f1d5\u003e] kmalloc_trace+0x26/0x60\n    [\u003c00000000a9c44622\u003e] phy_device_create+0x5d/0x970\n    [\u003c00000000d0ee2afc\u003e] get_phy_device+0xf3/0x2b0\n    [\u003c00000000dca0c71f\u003e] __fixed_phy_register.part.0+0x92/0x4e0\n    [\u003c000000008a834798\u003e] fixed_phy_register+0x84/0xb0\n    [\u003c0000000055223fcb\u003e] dsa_loop_init+0xa9/0x116 [dsa_loop]\n    ...\n\nThere are two reasons for memleak in dsa_loop_init().\n\nFirst, fixed_phy_register() create and register phy_device:\n\nfixed_phy_register()\n  get_phy_device()\n    phy_device_create() # freed by phy_device_free()\n  phy_device_register() # freed by phy_device_remove()\n\nBut fixed_phy_unregister() only calls phy_device_remove().\nSo the memory allocated in phy_device_create() is leaked.\n\nSecond, when mdio_driver_register() fail in dsa_loop_init(),\nit just returns and there is no cleanup for phydevs.\n\nFix the problems by catching the error of mdio_driver_register()\nin dsa_loop_init(), then calling both fixed_phy_unregister() and\nphy_device_free() to release phydevs.\nAlso add a function for phydevs cleanup to avoid duplacate.",
  "id": "GHSA-262g-44pp-38c2",
  "modified": "2025-05-07T15:31:28Z",
  "published": "2025-05-01T15:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49926"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c"
    }
  ],
  "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-2666-P2HQ-R258

Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-03-12 15:32
VLAI
Details

A memory leak issue discovered in parseSWF_TEXTRECORD in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-24150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-29T01:44:11Z",
    "severity": "MODERATE"
  },
  "details": "A memory leak issue discovered in parseSWF_TEXTRECORD in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file.",
  "id": "GHSA-2666-p2hq-r258",
  "modified": "2024-03-12T15:32:15Z",
  "published": "2024-02-29T03:33:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libming/libming/issues/309"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-26GF-57VW-HC28

Vulnerability from github – Published: 2022-09-16 00:00 – Updated: 2022-09-21 00:00
VLAI
Details

Mplayer SVN-r38374-13.0.1 is vulnerable to Memory Leak via vf.c and vf_vo.c.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-15T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Mplayer SVN-r38374-13.0.1 is vulnerable to Memory Leak via vf.c and vf_vo.c.",
  "id": "GHSA-26gf-57vw-hc28",
  "modified": "2022-09-21T00:00:38Z",
  "published": "2022-09-16T00:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38600"
    },
    {
      "type": "WEB",
      "url": "https://trac.mplayerhq.hu/ticket/2390#comment:2"
    }
  ],
  "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-26J6-P6XC-9625

Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2025-12-11 18:30
VLAI
Details

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

crypto: hisilicon/hpre - fix resource leak in remove process

In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T12:15:33Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/hpre - fix resource leak in remove process\n\nIn hpre_remove(), when the disable operation of qm sriov failed,\nthe following logic should continue to be executed to release the\nremaining resources that have been allocated, instead of returning\ndirectly, otherwise there will be resource leakage.",
  "id": "GHSA-26j6-p6xc-9625",
  "modified": "2025-12-11T18:30:35Z",
  "published": "2025-10-01T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50420"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b3e3ecdb402ff1053ee25b598ff21b9ddf4384f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/45e6319bd5f2154d8b8c9f1eaa4ac030ba0d330c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4e0de941d252d4e7c985981e78480c8d6f020b64"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cb873c93a7ad27681920bf062ef052fca1e8d5b1"
    }
  ],
  "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-273R-Q5CP-P9C2

Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2026-04-24 15:32
VLAI
Details

A memory leak was discovered in image_buffer_resize in fromsixel.c in libsixel 1.8.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-20023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-772"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-27T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A memory leak was discovered in image_buffer_resize in fromsixel.c in libsixel 1.8.4.",
  "id": "GHSA-273r-q5cp-p9c2",
  "modified": "2026-04-24T15:32:16Z",
  "published": "2022-05-24T17:05:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20023"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saitoha/libsixel/issues/120"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-277J-7GG4-FP2X

Vulnerability from github – Published: 2023-01-13 00:30 – Updated: 2023-01-13 00:30
VLAI
Details

A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Networks Junos OS on MX Series platforms with MPC10/MPC11 line cards, allows an unauthenticated adjacent attacker to cause a Denial of Service (DoS). Devices are only vulnerable when the Suspicious Control Flow Detection (scfd) feature is enabled. Upon enabling this specific feature, an attacker sending specific traffic is causing memory to be allocated dynamically and it is not freed. Memory is not freed even after deactivating this feature. Sustained processing of such traffic will eventually lead to an out of memory condition that prevents all services from continuing to function, and requires a manual restart to recover. The FPC memory usage can be monitored using the CLI command "show chassis fpc". On running the above command, the memory of AftDdosScfdFlow can be observed to detect the memory leak. This issue affects Juniper Networks Junos OS on MX Series: All versions prior to 20.2R3-S5; 20.3 version 20.3R1 and later versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-22410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-13T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Networks Junos OS on MX Series platforms with MPC10/MPC11 line cards, allows an unauthenticated adjacent attacker to cause a Denial of Service (DoS). Devices are only vulnerable when the Suspicious Control Flow Detection (scfd) feature is enabled. Upon enabling this specific feature, an attacker sending specific traffic is causing memory to be allocated dynamically and it is not freed. Memory is not freed even after deactivating this feature. Sustained processing of such traffic will eventually lead to an out of memory condition that prevents all services from continuing to function, and requires a manual restart to recover. The FPC memory usage can be monitored using the CLI command \"show chassis fpc\". On running the above command, the memory of AftDdosScfdFlow can be observed to detect the memory leak. This issue affects Juniper Networks Junos OS on MX Series: All versions prior to 20.2R3-S5; 20.3 version 20.3R1 and later versions.",
  "id": "GHSA-277j-7gg4-fp2x",
  "modified": "2023-01-13T00:30:37Z",
  "published": "2023-01-13T00:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22410"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA70206"
    }
  ],
  "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-27C2-9CC9-22V7

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

An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25603"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-670"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-23T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.",
  "id": "GHSA-27c2-9cc9-22v7",
  "modified": "2022-05-24T17:29:23Z",
  "published": "2022-05-24T17:29:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25603"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4JRXMKEMQRQYWYEPHVBIWUEAVQ3LU4FN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DA633Y3G5KX7MKRN4PFEGM3IVTJMBEOM"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RJZERRBJN6E6STDCHT4JHP4MI6TKBCJE"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202011-06"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4769"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-340.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00008.html"
    }
  ],
  "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-27FG-VF5M-QMJJ

Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2025-11-04 00:30
VLAI
Details

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

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-21T11:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: fix potential memory leak in vfio_intx_enable()\n\nIf vfio_irq_ctx_alloc() failed will lead to \u0027name\u0027 memory leak.",
  "id": "GHSA-27fg-vf5m-qmjj",
  "modified": "2025-11-04T00:30:49Z",
  "published": "2024-06-21T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38632"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0bd22a4966d55f1d2c127a53300d5c2b50152376"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35fef97c33f3d3ca0455f9a8e2a3f2c1f8cc9140"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82b951e6fbd31d85ae7f4feb5f00ddd4c5d256e2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91ced077db2062604ec270b1046f8337e9090079"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6d810554d7d9d07041f14c5fcd453f3d3fed594"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "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.