CWE-835

{
  "affected": [],
  "aliases": [
    "CVE-2024-50319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-12T16:15:23Z",
    "severity": "HIGH"
  },
  "details": "An infinite loop in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service.",
  "id": "GHSA-2w99-6h4v-j323",
  "modified": "2024-11-12T18:30:56Z",
  "published": "2024-11-12T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50319"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Avalanche-Multiple-CVEs-Q4-2024-Release"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-23352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-05T15:15:46Z",
    "severity": "HIGH"
  },
  "details": "Transient DOS when NAS receives ODAC criteria of length 1 and type 1 in registration accept OTA.",
  "id": "GHSA-2wc7-jrqh-277g",
  "modified": "2024-08-05T15:30:53Z",
  "published": "2024-08-05T15:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23352"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/august-2024-bulletin.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-42084"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-07T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Zammad before 4.1.1. An attacker with valid agent credentials may send a series of crafted requests that cause an endless loop and thus cause denial of service.",
  "id": "GHSA-2wm3-m74f-6p2x",
  "modified": "2022-05-24T19:16:52Z",
  "published": "2022-05-24T19:16:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42084"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/en/advisories/zaa-2021-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-7705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-12T23:59:00Z",
    "severity": "HIGH"
  },
  "details": "In Wireshark 2.2.0 to 2.2.5 and 2.0.0 to 2.0.11, the RPC over RDMA dissector could go into an infinite loop, triggered by packet injection or a malformed capture file. This was addressed in epan/dissectors/packet-rpcrdma.c by correctly checking for going beyond the maximum offset.",
  "id": "GHSA-2wm6-mgmh-92vr",
  "modified": "2025-04-20T03:36:01Z",
  "published": "2022-05-13T01:47:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7705"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13558"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git%3Ba=commit%3Bh=08d392bbecc8fb666bf979e70a34536007b83ea2"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=08d392bbecc8fb666bf979e70a34536007b83ea2"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201706-12"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2017-15.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97630"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038262"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-21681"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T12:15:29Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix lockup on tx to unregistering netdev with carrier\n\nCommit in a fixes tag attempted to fix the issue in the following\nsequence of calls:\n\n    do_output\n    -\u003e ovs_vport_send\n       -\u003e dev_queue_xmit\n          -\u003e __dev_queue_xmit\n             -\u003e netdev_core_pick_tx\n                -\u003e skb_tx_hash\n\nWhen device is unregistering, the \u0027dev-\u003ereal_num_tx_queues\u0027 goes to\nzero and the \u0027while (unlikely(hash \u003e= qcount))\u0027 loop inside the\n\u0027skb_tx_hash\u0027 becomes infinite, locking up the core forever.\n\nBut unfortunately, checking just the carrier status is not enough to\nfix the issue, because some devices may still be in unregistering\nstate while reporting carrier status OK.\n\nOne example of such device is a net/dummy.  It sets carrier ON\non start, but it doesn\u0027t implement .ndo_stop to set the carrier off.\nAnd it makes sense, because dummy doesn\u0027t really have a carrier.\nTherefore, while this device is unregistering, it\u0027s still easy to hit\nthe infinite loop in the skb_tx_hash() from the OVS datapath.  There\nmight be other drivers that do the same, but dummy by itself is\nimportant for the OVS ecosystem, because it is frequently used as a\npacket sink for tcpdump while debugging OVS deployments.  And when the\nissue is hit, the only way to recover is to reboot.\n\nFix that by also checking if the device is running.  The running\nstate is handled by the net core during unregistering, so it covers\nunregistering case better, and we don\u0027t really need to send packets\nto devices that are not running anyway.\n\nWhile only checking the running state might be enough, the carrier\ncheck is preserved.  The running and the carrier states seem disjoined\nthroughout the code and different drivers.  And other core functions\nlike __dev_direct_xmit() check both before attempting to transmit\na packet.  So, it seems safer to check both flags in OVS as well.",
  "id": "GHSA-2x4f-r6q9-v77h",
  "modified": "2025-11-03T21:32:30Z",
  "published": "2025-01-31T12:33:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21681"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/47e55e4b410f7d552e43011baa5be1aab4093990"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82f433e8dd0629e16681edf6039d094b5518d8ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87fcf0d137c770e6040ebfdb0abd8e7dd481b504"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/930268823f6bccb697aa5d2047aeffd4a497308c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b5c73fc92f8d15c16e5dc87b5c17d2abf1e6d092"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ea966b6698785fb9cd0fdb867acd91b222e4723f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ea9e990356b7bee95440ba0e6e83cc4d701afaca"
    },
    {
      "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "iodine"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.7.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:41:06Z",
    "nvd_published_at": "2026-04-22T02:16:02Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`fio_json_parse` can enter an infinite loop when it encounters a nested JSON value starting with `i` or `I`. The process spins in user space and pegs one CPU core at ~100% instead of returning a parse error. Because `iodine` vendors the same parser code, the issue also affects `iodine` when it parses attacker-controlled JSON.\n\nThe smallest reproducer found is `[i`. The quoted-value form that originally exposed the issue, `[\"\"i`, reaches the same bug because the parser tolerates missing commas and then treats the trailing `i` as the start of another value.\n\n### Details\nThe vulnerable logic is in `lib/facil/fiobj/fio_json_parser.h` around the numeral handling block (`0.7.5` / `0.7.6`: lines `434-468`; `master`: lines `434-468` in the current tree as tested).\n\nThis parser is reached from real library entry points, not just the header in isolation:\n\n- `facil.io`: `lib/facil/fiobj/fiobj_json.c:377-387` (`fiobj_json2obj`) and `402-411` (`fiobj_hash_update_json`)\n- `iodine`: `ext/iodine/iodine_json.c:161-177` (`iodine_json_convert`)\n- `iodine`: `ext/iodine/fiobj_json.c:377-387` and `402-411`\n\nRelevant flow:\n\n1. Inside an array or object, the parser sees `i` or `I` and jumps to the `numeral:` label.\n2. It calls `fio_atol((char **)\u0026tmp)`.\n3. For a bare `i` / `I`, `fio_atol` consumes zero characters and leaves `tmp == pos`.\n4. The current code only falls back to float parsing when `JSON_NUMERAL[*tmp]` is true.\n5. `JSON_NUMERAL[\u0027i\u0027] == 0`, so the parser incorrectly accepts the value as an integer and sets `pos = tmp` without advancing.\n6. Because parsing is still nested (`parser-\u003edepth \u003e 0`), the outer loop continues forever with the same `pos`.\n\nThe same logic exists in `iodine`\u0027s vendored copy at `ext/iodine/fio_json_parser.h` lines `434-468`.\n\nWhy the `[\"\"i` form hangs:\n\n1. The parser accepts the empty string `\"\"` as the first array element.\n2. It does not require a comma before the next token.\n3. The trailing `i` is then parsed as a new nested value.\n4. The zero-progress numeral path above causes the infinite loop.\n\nExamples that trigger the bug:\n\n- Array form, minimal: `[i`\n- Object form: `{\"a\":i`\n- After a quoted value in an array: `[\"\"i`\n- After a quoted value in an object: `{\"a\":\"\"i`\n\n## PoC\nEnvironment used for verification:\n\n- `facil.io` commit: `162df84001d66789efa883eebb0567426d00148e`\n- `iodine` commit: `5bebba698d69023cf47829afe51052f8caa6c7f8`\n- standalone compile against `fio_json_parser.h`\n\n### Minimal standalone program\n\nUse the normal HTTP stack. The following server calls `http_parse_body(h)`, which reaches `fiobj_json2obj` and then `fio_json_parse` for `Content-Type: application/json`.\n\n```c\n#define _POSIX_C_SOURCE 200809L\n\n#include \u003cstdio.h\u003e\n#include \u003ctime.h\u003e\n#include \u003cfio.h\u003e\n#include \u003chttp.h\u003e\n\nstatic void on_request(http_s *h) {\n  fprintf(stderr, \"calling http_parse_body\\n\");\n  fflush(stderr);\n  http_parse_body(h);\n  fprintf(stderr, \"returned from http_parse_body\\n\");\n  http_send_body(h, \"ok\\n\", 3);\n}\n\nint main(void) {\n  if (http_listen(\"3000\", \"127.0.0.1\",\n                  .on_request = on_request,\n                  .max_body_size = (1024 * 1024),\n                  .log = 1) == -1) {\n    perror(\"http_listen\");\n    return 1;\n  }\n  fio_start(.threads = 1, .workers = 1);\n  return 0;\n}\n```\n\n`http_parse_body(h)` is the higher-level entry point and, for `Content-Type: application/json`, it reaches `fiobj_json2obj` in `lib/facil/http/http.c:1947-1953`.\n\nSave it as `src/main.c` in a vulnerable `facil.io` checkout and build it with the repo `makefile`:\n\n```bash\ngit checkout 0.7.6\nmkdir -p src\nmake NAME=http_json_poc\n```\n\nRun:\n\n```bash\n./tmp/http_json_poc\n```\n\nThen in another terminal send one of these payloads:\n\n```bash\nprintf \u0027[i\u0027 | curl --http1.1 -H \u0027Content-Type: application/json\u0027 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027{\"a\":i\u0027 | curl --http1.1 -H \u0027Content-Type: application/json\u0027 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027[\"\"i\u0027 | curl --http1.1 -H \u0027Content-Type: application/json\u0027 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027{\"a\":\"\"i\u0027 | curl --http1.1 -H \u0027Content-Type: application/json\u0027 -X POST --data-binary @- http://127.0.0.1:3000/\n```\n\nObserved result on a vulnerable build:\n\n- The server prints `calling http_parse_body` and never reaches `returned from http_parse_body`.\n- The request never completes.\n- One worker thread spins until the process is killed.\n\n### Downstream impact in `iodine`\n\n`iodine` vendors the same parser implementation in `ext/iodine/fio_json_parser.h`, so any `iodine` code path that parses attacker-controlled JSON through this parser inherits the same hang / CPU exhaustion behavior.\n\nSingle-file `iodine` HTTP server repro:\n\n```ruby\nrequire \"iodine\"\n\nAPP = proc do |env|\n  body = env[\"rack.input\"].read.to_s\n  warn \"calling Iodine::JSON.parse on: #{body.inspect}\"\n  Iodine::JSON.parse(body)\n  warn \"returned from Iodine::JSON.parse\"\n  [200, { \"Content-Type\" =\u003e \"text/plain\", \"Content-Length\" =\u003e \"3\" }, [\"ok\\n\"]]\nend\n\nIodine.listen service: :http,\n              address: \"127.0.0.1\",\n              port: \"3000\",\n              handler: APP\n\nIodine.threads = 1\nIodine.workers = 1\nIodine.start\n```\n\nRun:\n\n```bash\nruby iodine_json_parse_http_poc.rb\n```\n\nThen in a second terminal:\n\n```bash\nprintf \u0027[i\u0027 | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027{\"a\":i\u0027 | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027[\"\"i\u0027 | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/\nprintf \u0027{\"a\":\"\"i\u0027 | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/\n```\n\nOn a vulnerable build, the server prints the `calling Iodine::JSON.parse...` line but never prints the `returned from Iodine::JSON.parse` line for these payloads.\n\n## Impact\nThis is a denial-of-service issue. An attacker who can supply JSON to an affected parser path can cause the process to spin indefinitely and consume CPU at roughly 100% of one core. In practice, the impact depends on whether an application exposes parser access to untrusted clients, but for services that do, a single crafted request can tie up a worker or thread until it is killed or restarted.\n\nI would describe the impact as:\n\n- Availability impact: high for affected parser entry points\n- Confidentiality impact: none observed\n- Integrity impact: none observed\n\n## Suggested Patch\nTreat zero-consumption numeric parses as failures before accepting the token.\n\n```diff\ndiff --git a/lib/facil/fiobj/fio_json_parser.h b/lib/facil/fiobj/fio_json_parser.h\n@@\n       uint8_t *tmp = pos;\n       long long i = fio_atol((char **)\u0026tmp);\n       if (tmp \u003e limit)\n         goto stop;\n-      if (!tmp || JSON_NUMERAL[*tmp]) {\n+      if (!tmp || tmp == pos || JSON_NUMERAL[*tmp]) {\n         tmp = pos;\n         double f = fio_atof((char **)\u0026tmp);\n         if (tmp \u003e limit)\n           goto stop;\n-        if (!tmp || JSON_NUMERAL[*tmp])\n+        if (!tmp || tmp == pos || JSON_NUMERAL[*tmp])\n           goto error;\n         fio_json_on_float(parser, f);\n         pos = tmp;\n```\n\nThis preserves permissive `inf` / `nan` handling when the float parser actually consumes input, but rejects bare `i` / `I` tokens that otherwise leave the cursor unchanged.\n\nThe same change should be mirrored to `iodine`\u0027s vendored copy:\n\n- `ext/iodine/fio_json_parser.h`\n\n\n## Impact\n- `facil.io`\n  - Verified on `master` commit `162df84001d66789efa883eebb0567426d00148e` (`git describe`: `0.7.5-24-g162df840`)\n  - Verified on tagged releases `0.7.5` and `0.7.6`\n- `iodine` Ruby gem\n  - Verified on repo commit `5bebba698d69023cf47829afe51052f8caa6c7f8`\n  - Verified on tag / gem version `v0.7.58`\n  - The gem vendors a copy of the vulnerable parser in `ext/iodine/fio_json_parser.h`",
  "id": "GHSA-2x79-gwq3-vxxm",
  "modified": "2026-06-08T23:17:40Z",
  "published": "2026-04-14T23:41:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/boazsegev/facil.io/security/advisories/GHSA-2x79-gwq3-vxxm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/boazsegev/facil.io/commit/5128747363055201d3ecf0e29bf0a961703c9fa0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/boazsegev/facil.io"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/iodine/CVE-2026-41146.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Uncontrolled resource consumption and loop with unreachable exit condition in facil.io and downstream iodine ruby gem"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.23"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tika:tika"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0"
            },
            {
              "fixed": "1.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-1951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-05T22:47:57Z",
    "nvd_published_at": "2020-03-23T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A carefully crafted or corrupt PSD file can cause an infinite loop in Apache Tika\u0027s PSDParser in versions 1.0-1.23.",
  "id": "GHSA-3264-3fm9-fg44",
  "modified": "2022-10-07T20:40:10Z",
  "published": "2021-05-07T15:54:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1951"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tika"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd8c1b42bd0e31870d804890b3f00b13d837c528f7ebaf77031323172%40%3Cdev.tika.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/03/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4564-1"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
    }
  ],
  "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"
    }
  ],
  "summary": "Infinite Loop in Apache Tika"
}

{
  "affected": [],
  "aliases": [
    "CVE-2010-0207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-30T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In xpdf, the xref table contains an infinite loop which allows remote attackers to cause a denial of service (application crash) in xpdf-based PDF viewers.",
  "id": "GHSA-3274-8h4c-g6q9",
  "modified": "2024-04-03T23:04:23Z",
  "published": "2022-04-21T01:57:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-0207"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0207"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2010-0207"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-53685"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-11T13:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: give up on paths longer than PATH_MAX\n\nIf the full path to be built by ceph_mdsc_build_path() happens to be\nlonger than PATH_MAX, then this function will enter an endless (retry)\nloop, effectively blocking the whole task.  Most of the machine\nbecomes unusable, making this a very simple and effective DoS\nvulnerability.\n\nI cannot imagine why this retry was ever implemented, but it seems\nrather useless and harmful to me.  Let\u0027s remove it and fail with\nENAMETOOLONG instead.",
  "id": "GHSA-32jq-w4j4-wjvc",
  "modified": "2025-11-03T21:32:07Z",
  "published": "2025-01-11T15:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53685"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f2b2d9e881c90402dbe28f9ba831775b7992e1f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/550f7ca98ee028a606aa75705a7e77b1bd11720f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/99a37ab76a315c8307eb5b0dc095d8ad9d8efeaa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c47ed91156daf328601d02b58d52d9804da54108"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d42ad3f161a5a487f81915c406f46943c7187a0a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e4b168c64da06954be5d520f6c16469b1cadc069"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-4890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-11T18:16:41Z",
    "severity": "HIGH"
  },
  "details": "A Denial of Service (DoS) vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to cause a denial of service via a crafted DNS packet.",
  "id": "GHSA-32px-jfgq-53xf",
  "modified": "2026-07-02T12:30:43Z",
  "published": "2026-05-11T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NixOS/nixpkgs/pull/519082"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NixOS/nixpkgs/pull/519093"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19158"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19373"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20589"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:34508"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-4890"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2458516"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pi-hole/FTL/releases/tag/v6.6.2"
    },
    {
      "type": "WEB",
      "url": "https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q2/018471.html"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4890.json"
    },
    {
      "type": "WEB",
      "url": "https://thekelleys.org.uk/dnsmasq"
    },
    {
      "type": "WEB",
      "url": "https://thekelleys.org.uk/dnsmasq/CVE"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/471747"
    }
  ],
  "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"
    }
  ]
}