jq vulnerabilities

The jv_dump_term function in jq 1.5 allows remote attackers to cause a denial of service via a crafted JSON file, leading to stack consumption and application crash. This issue has been fixed in jq 1.6_rc1-r0.

The decNumberCopy function 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. This can be demonstrated by using --slurp with subtraction, such as a filter of .-. when the input has a certain form.

Off-by-one error in the tokenadd function in jv_parse.c in jq allows remote attackers to cause a denial of service (crash) via a long JSON-encoded number, which triggers a heap-based buffer overflow.

Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, allowing an attacker to precompute key collisions offline. A crafted JSON object (~100 KB) with all keys hashing to the same bucket degrades lookups from O(1) to O(n), causing CPU exhaustion.

In the libjq library (part of the jq tool), the jv_parse_sized() function has an out-of-bounds read vulnerability. When processing malformed JSON in a non-NUL-terminated buffer, the error formatting function uses %s which reads until a NUL terminator, ignoring the caller-supplied length.