jq --rawfile invalid-state reuse after String too long causes heap-buffer-overflow

jq is a command-line JSON processor. Prior to 1.8.2, on 32bit system, jvpstringappend has a chance of integer/multiple overflowing and then causing a massive buffer overrun. This vulnerability is fixed in 1.8.2.

jq is a command-line JSON processor. In 1.8.2rc1 and earlier, the ordinary module loader recurses without cycle detection when two otherwise valid modules include each other.

jq is a command-line JSON processor. In 1.8.1 and earlier, jvcontains recurses into nested arrays/objects with no depth limit. With a sufficiently nested input structure (built programmatically with reduce, since the JSON parser caps at depth 10000), the C stack is exhausted.

jq is a command-line JSON processor. Prior to version 1.8.2, the strindices builtin in jq's src/builtin.c passes its arguments directly to jvstringindexes() without verifying they are strings, and jvstringindexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03, which is part of version 1.8.2.

jq is a command-line JSON processor. In versions 1.8.1 and below, functions jvsetpath(), jvgetpath(), and delpathssorted() in jq's src/jvaux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAXPARSINGDEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq's setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.

jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvpstringappend() and jvpstringcopyreplacebad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.

jq is a command-line JSON processor. In versions up to and including 1.7.1, a heap-buffer-overflow is present in function jvstringvfmt in the jqfuzzexecute harness from oss-fuzz. This crash happens on file jv.c, line 1456 void p = malloc(sz);. As of time of publication, no patched versions are available.

AddressSanitizer: stack-buffer-overflow in jqfuzzexecute (jvstringvfmt)

jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.

jq has signed integer overflow in jv.c:jvparraywrite

decNumberCopy in decNumber.c in jq through 1.7.1 does not properly consider that NaN is interpreted as numeric, which has a resultant stack-based buffer overflow and out-of-bounds write, as demonstrated by use of --slurp with subtraction, such as a filter of .-. when the input has a certain form of digit string with NaN (e.g., "1 NaN123" immediately followed by many more digits).

https://github.com/jqlang/jq/releases/tag/jq-1.7.1 lists these two fixes among the changes in this week's release of jq 1.7.1:

CVE-2023-50246: Fix heap buffer overflow in jvpliteralnumberliteral CVE-2023-50268: fix stack-buffer-overflow if comparing nan with payload

They've also published advisories on github for each:

[oss-fuzz] Issue 64771: jq:jqfuzzexecute: Stack-buffer-overflow in decNaNs https://github.com/jqlang/jq/security/advisories/GHSA-7hmr-442f-qc8j

heap-buffer-overflow exists in the function decToString in decNumber.c https://github.com/jqlang/jq/security/advisories/GHSA-686w-5m7m-54vc

The fixes appear to be in: https://github.com/jqlang/jq/commit/c9a51565214eece8f1053089739aea73145bfd6b https://github.com/jqlang/jq/commit/71c2ab509a8628dbbad4bc7b3f98a64aa90d3297

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris