Common Weakness Enumeration

CWE-617

Allowed

Reachable Assertion

Abstraction: Base · Status: Draft

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

989 vulnerabilities reference this CWE, most recent first.

GHSA-4765-GCH7-M8CW

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

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

closures: Change BUG_ON() to WARN_ON()

If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON()

For reference, this has popped up once in the CI, and we'll need more info to debug it:

03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42252"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-08T09:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclosures: Change BUG_ON() to WARN_ON()\n\nIf a BUG_ON() can be hit in the wild, it shouldn\u0027t be a BUG_ON()\n\nFor reference, this has popped up once in the CI, and we\u0027ll need more\ninfo to debug it:\n\n03240 ------------[ cut here ]------------\n03240 kernel BUG at lib/closure.c:21!\n03240 kernel BUG at lib/closure.c:21!\n03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n03240 Modules linked in:\n03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570\n03240 Hardware name: linux,dummy-virt (DT)\n03240 Workqueue: btree_update btree_interior_update_work\n03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)\n03240 pc : closure_put+0x224/0x2a0\n03240 lr : closure_put+0x24/0x2a0\n03240 sp : ffff0000d12071c0\n03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360\n03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040\n03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168\n03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001\n03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974\n03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d\n03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e\n03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b\n03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954\n03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000\n03240 Call trace:\n03240  closure_put+0x224/0x2a0\n03240  bch2_check_for_deadlock+0x910/0x1028\n03240  bch2_six_check_for_deadlock+0x1c/0x30\n03240  six_lock_slowpath.isra.0+0x29c/0xed0\n03240  six_lock_ip_waiter+0xa8/0xf8\n03240  __bch2_btree_node_lock_write+0x14c/0x298\n03240  bch2_trans_lock_write+0x6d4/0xb10\n03240  __bch2_trans_commit+0x135c/0x5520\n03240  btree_interior_update_work+0x1248/0x1c10\n03240  process_scheduled_works+0x53c/0xd90\n03240  worker_thread+0x370/0x8c8\n03240  kthread+0x258/0x2e8\n03240  ret_from_fork+0x10/0x20\n03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000)\n03240 ---[ end trace 0000000000000000 ]---\n03240 Kernel panic - not syncing: Oops - BUG: Fatal exception\n03240 SMP: stopping secondary CPUs\n03241 SMP: failed to stop secondary CPUs 13,15\n03241 Kernel Offset: disabled\n03241 CPU features: 0x00,00000003,80000008,4240500b\n03241 Memory Limit: none\n03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---\n03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s",
  "id": "GHSA-4765-gch7-m8cw",
  "modified": "2025-11-03T21:31:11Z",
  "published": "2024-08-08T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42252"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/339b84ab6b1d66900c27bd999271cb2ae40ce812"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5d85f2ab79d5918a66539ebf046c099f7448db8d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c894a74756478bb7aec894bcc513add3d554c0cf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ecb4aaa658da760fb83afd79cc5fd4360aa60635"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/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-47M2-4CR7-MHCW

Vulnerability from github – Published: 2025-10-10 17:03 – Updated: 2025-11-05 22:06
VLAI
Summary
quic-go: Panic occurs when queuing undecryptable packets after handshake completion
Details

Summary

A misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.

Impact

A misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC).

Affected Versions

  • All versions prior to v0.49.1 (for the 0.49 branch)
  • Versions v0.50.0 to v0.54.0 (inclusive)
  • Fixed in v0.49.1, v0.54.1, and v0.55.0 onward

Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.

Details

For a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:

  • Initial keys (derived from a static key and the connection ID)
  • Handshake keys (derived from the client's and server's key shares in the TLS handshake)
  • 1-RTT keys (derived when the TLS handshake finishes)

On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.

Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.

After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake.

A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.

This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets).

The Fix

quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/quic-go/quic-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.49.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/quic-go/quic-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.50.0"
            },
            {
              "fixed": "0.54.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-10T17:03:01Z",
    "nvd_published_at": "2025-10-10T16:15:52Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.\n\n## Impact\n\nA misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana\u0027s Firedancer QUIC).\n\n## Affected Versions\n\n- All versions prior to v0.49.1 (for the 0.49 branch)\n- Versions v0.50.0 to v0.54.0 (inclusive)\n- Fixed in v0.49.1, v0.54.1, and v0.55.0 onward\n\nUsers are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.\n\n## Details\n\nFor a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:\n\n- Initial keys (derived from a static key and the connection ID)\n- Handshake keys (derived from the client\u0027s and server\u0027s key shares in the TLS handshake)\n- 1-RTT keys (derived when the TLS handshake finishes)\n\nOn the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server\u0027s HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.\n\nDue to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server\u0027s Handshake packets (containing, among others, the TLS certificate) might arrive before the server\u0027s Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.\n\nAfter completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an [assertion](https://github.com/quic-go/quic-go/blob/v0.55.0/connection.go#L2682-L2685) that no packets are queued after completion of the handshake.\n\nA misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.\n\nThis can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client\u0027s TLS Finished message (which is sent in Handshake packets).\n\n## The Fix\n\nquic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.",
  "id": "GHSA-47m2-4cr7-mhcw",
  "modified": "2025-11-05T22:06:25Z",
  "published": "2025-10-10T17:03:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/security/advisories/GHSA-47m2-4cr7-mhcw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/pull/5354"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/commit/bc5bccf10fd02728eef150683eb4dfaa5c0e749c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/commit/ce7c9ea8834b9d2ed79efa9269467f02c0895d42"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/quic-go/quic-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/blob/v0.55.0/connection.go#L2682-L2685"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-4017"
    }
  ],
  "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": "quic-go: Panic occurs when queuing undecryptable packets after handshake completion"
}

GHSA-47V5-J4QC-P3GP

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-11-24 21:30
VLAI
Details

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

drm/xe/migrate: prevent infinite recursion

If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to using a bounce buffer. However the bounce buffer here is allocated on the stack, and the only alignment requirement here is that it's naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce buffer is also misaligned we then recurse back into the function again, however the new bounce buffer might also not be aligned, and might never be until we eventually blow through the stack, as we keep recursing.

Instead of using the stack use kmalloc, which should respect the power-of-two alignment request here. Fixes a kernel panic when triggering this path through eudebug.

v2 (Stuart): - Add build bug check for power-of-two restriction - s/EINVAL/ENOMEM/

(cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T16:15:37Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/migrate: prevent infinite recursion\n\nIf the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to\nusing a bounce buffer. However the bounce buffer here is allocated on\nthe stack, and the only alignment requirement here is that it\u0027s\nnaturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce\nbuffer is also misaligned we then recurse back into the function again,\nhowever the new bounce buffer might also not be aligned, and might never\nbe until we eventually blow through the stack, as we keep recursing.\n\nInstead of using the stack use kmalloc, which should respect the\npower-of-two alignment request here. Fixes a kernel panic when\ntriggering this path through eudebug.\n\nv2 (Stuart):\n - Add build bug check for power-of-two restriction\n - s/EINVAL/ENOMEM/\n\n(cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff)",
  "id": "GHSA-47v5-j4qc-p3gp",
  "modified": "2025-11-24T21:30:56Z",
  "published": "2025-09-05T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38690"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/89f511c024879c5812cc0c010a6663b5e49950f3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d7a1cbebbb691891671def57407ba2f8ee914e8"
    }
  ],
  "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-484W-F535-WHCJ

Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2025-01-16 18:30
VLAI
Details

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

btrfs: remove BUG() after failure to insert delayed dir index item

Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path).

So remove the BUG() call and do proper error handling.

This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-02T22:15:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: remove BUG() after failure to insert delayed dir index item\n\nInstead of calling BUG() when we fail to insert a delayed dir index item\ninto the delayed node\u0027s tree, we can just release all the resources we\nhave allocated/acquired before and return the error to the caller. This is\nfine because all existing call chains undo anything they have done before\ncalling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending\nsnapshots in the transaction commit path).\n\nSo remove the BUG() call and do proper error handling.\n\nThis relates to a syzbot report linked below, but does not fix it because\nit only prevents hitting a BUG(), it does not fix the issue where somehow\nwe attempt to use twice the same index number for different index items.",
  "id": "GHSA-484w-f535-whcj",
  "modified": "2025-01-16T18:30:57Z",
  "published": "2024-03-03T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52569"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51"
    }
  ],
  "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-48M6-486P-9J8P

Vulnerability from github – Published: 2026-04-13 16:36 – Updated: 2026-04-15 20:56
VLAI
Summary
nimiq-consensus panics via RequestMacroChain micro-block locator
Details

Impact

An unauthenticated p2p peer can cause the RequestMacroChain message handler task to panic by sending a RequestMacroChain message where the first locator hash that is on the victim’s main chain is a micro block hash (not a macro block hash).

In RequestMacroChain::handle, the handler selects the locator based only on "is on main chain", then calls get_macro_blocks() and panics via .unwrap() when the selected hash is not a macro block (BlockchainError::BlockIsNotMacro).

Patches

The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3660) is formally released as part of v1.3.0.

Workarounds

No known workarounds.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "nimiq-consensus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-13T16:36:00Z",
    "nvd_published_at": "2026-04-14T00:16:07Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n An unauthenticated p2p peer can cause the `RequestMacroChain` message handler task to panic by sending a `RequestMacroChain` message where the first locator hash that is on the victim\u2019s main chain is a micro block hash (not a macro block hash).\n\nIn `RequestMacroChain::handle`, the handler selects the locator based only on \"is on main chain\", then calls `get_macro_blocks()` and panics via `.unwrap()` when the selected hash is not a macro block (`BlockchainError::BlockIsNotMacro`).\n\n### Patches\nThe patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3660) is formally released as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).\n\n### Workarounds\nNo known workarounds.",
  "id": "GHSA-48m6-486p-9j8p",
  "modified": "2026-04-15T20:56:41Z",
  "published": "2026-04-13T16:36:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-48m6-486p-9j8p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34069"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/pull/3660"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/commit/ae6c1e92342e72f80fd12accbe66ee80dd6802ac"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nimiq/core-rs-albatross"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nimiq-consensus panics via RequestMacroChain micro-block locator"
}

GHSA-48MV-8MQ9-RHMF

Vulnerability from github – Published: 2022-08-04 00:00 – Updated: 2022-08-10 00:00
VLAI
Details

The assertion `stmt->Dbc->FirstStmt' failed in MonetDB Database Server v11.43.13.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34967"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-03T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "The assertion `stmt-\u003eDbc-\u003eFirstStmt\u0027 failed in MonetDB Database Server v11.43.13.",
  "id": "GHSA-48mv-8mq9-rhmf",
  "modified": "2022-08-10T00:00:20Z",
  "published": "2022-08-04T00:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34967"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MonetDB/MonetDB/issues/7306"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48PM-MHWH-G6MR

Vulnerability from github – Published: 2022-04-15 00:00 – Updated: 2022-04-22 00:01
VLAI
Details

There is an Assertion failure in MariaDB Server v10.9 and below via 'node->pcur->rel_pos == BTR_PCUR_ON' at /row/row0mysql.cc.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-27448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-14T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is an Assertion failure in MariaDB Server v10.9 and below via \u0027node-\u003epcur-\u003erel_pos == BTR_PCUR_ON\u0027 at /row/row0mysql.cc.",
  "id": "GHSA-48pm-mhwh-g6mr",
  "modified": "2022-04-22T00:01:01Z",
  "published": "2022-04-15T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27448"
    },
    {
      "type": "WEB",
      "url": "https://jira.mariadb.org/browse/MDEV-28095"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220526-0006"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48RG-6M8G-CQGC

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2024-03-21 03:34
VLAI
Details

Unbound before 1.9.5 allows an assertion failure via a compressed name in dname_pkt_copy.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-25041"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-27T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "Unbound before 1.9.5 allows an assertion failure via a compressed name in dname_pkt_copy.",
  "id": "GHSA-48rg-6m8g-cqgc",
  "modified": "2024-03-21T03:34:04Z",
  "published": "2022-05-24T17:48:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25041"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210507-0007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4CJW-RPHC-C5V6

Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-07-09 00:31
VLAI
Details

A denial of service vulnerability was found in GStreamer's AV1 codec parser in gst-plugins-bad. The gst_av1_parser_parse_tile_list_obu() function passes a byte count to a bit-reader API that expects a bit count, causing parser desynchronization. A remote attacker could trick a user into opening a specially crafted AV1 media file, triggering an assertion abort and causing the application to crash.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T20:16:32Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service vulnerability was found in GStreamer\u0027s AV1 codec parser in gst-plugins-bad. The gst_av1_parser_parse_tile_list_obu() function passes a byte count to a bit-reader API that expects a bit count, causing parser desynchronization. A remote attacker could trick a user into opening a specially crafted AV1 media file, triggering an assertion abort and causing the application to crash.",
  "id": "GHSA-4cjw-rphc-c5v6",
  "modified": "2026-07-09T00:31:13Z",
  "published": "2026-06-15T21:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52718"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36749"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36834"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-52718"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2486328"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5103"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4CXM-8XRJ-7C53

Vulnerability from github – Published: 2022-05-13 01:39 – Updated: 2022-05-13 01:39
VLAI
Details

The hidden-service feature in Tor before 0.3.0.8 allows a denial of service (assertion failure and daemon exit) in the connection_edge_process_relay_cell function via a BEGIN_DIR cell on a rendezvous circuit.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-0376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-09T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "The hidden-service feature in Tor before 0.3.0.8 allows a denial of service (assertion failure and daemon exit) in the connection_edge_process_relay_cell function via a BEGIN_DIR cell on a rendezvous circuit.",
  "id": "GHSA-4cxm-8xrj-7c53",
  "modified": "2022-05-13T01:39:57Z",
  "published": "2022-05-13T01:39:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0376"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torproject/tor/commit/56a7c5bc15e0447203a491c1ee37de9939ad1dcd"
    },
    {
      "type": "WEB",
      "url": "https://lists.torproject.org/pipermail/tor-announce/2017-June/000131.html"
    },
    {
      "type": "WEB",
      "url": "https://trac.torproject.org/projects/tor/ticket/22494"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3877"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)

Mitigation
Implementation

Strategy: Input Validation

Perform input validation on user data.

No CAPEC attack patterns related to this CWE.