Debian Patches

Status for jq/1.7.1-6+deb13u3

Patch Description Author Forwarded Bugs Origin Last update
patch-version-into-build.patch Set release version manually.
jq sets the build version by parsing the git branch. There is no git branch during
package building however. This patch sets the version manually. The version can be
looked up using `git describe --tags --match 'upstream*' | sed 's/^upstream\///'`.		 "ChangZhuo Chen (陳昌倬)" yes upstream 2014-06-21
dont-distribute-duplicate-docs.patch Do not distribute COPYING, fixes lintian warning "ChangZhuo Chen (陳昌倬)" not-needed 2015-10-11
0008-Do-not-use-venderized-oniguruma.patch Do not use venderized oniguruma "ChangZhuo Chen (陳昌倬)" no 2018-11-04
disable-static-libtool.patch Ensure jq doesn't statically link in libraries Harlan Lieberman-Berg <hlieberman@debian.org> not-needed 2018-11-04
0006-Do-not-use-pipenv-to-build-docs.patch Do not use pipenv to build docs "ChangZhuo Chen (陳昌倬)" no 2023-09-13
libtool.patch no
CVE-2024-53427.patch Reject NaN with payload while parsing JSON (CVE-2024-53427) decNumberFromString() parses "NaN123" as a NaN carrying the payload 123.
Such values then flow into the comparison and printing paths, where the
payload digits are treated as significant, and CVE-2024-53427 is the
resulting unbounded recursion.
.
Upstream rejects a literal NaN that carries a payload, and returns a plain
native NaN for a bare "NaN". The check belongs in a decNumberIsNaN() branch:
decNumberFromString() reports a *successful* conversion for "NaN123", so
DEC_Conversion_syntax is not set and that branch is never taken for the
inputs this CVE is about.
.
The version of this patch shipped in 1.7.1-5 (and hence in trixie as
1.7.1-6+deb13u2) placed the payload check inside the DEC_Conversion_syntax
branch, which already returns JV_INVALID unconditionally on the two lines
that follow it. The added block was therefore a no-op and the issue remained
unfixed: "NaN123" still parsed. Verified against the built package --
echo NaN123 | jq . printed null with exit status 0. This revision moves the
check to the correct branch, which makes the same input fail to parse.
.
The tests/jq.test stanza that asserted "nan1234" parses, and the
CVE-2023-50268 Nan4000 case in tests/shtest, both encode the old behaviour
and are updated as upstream does.
introduced as part of a jv_number_value() caching refactor. Only the branch
itself is backported here; the caching change is a performance optimisation
that is not needed for the fix and would touch the jv number representation.

===================================================================		 ChangZhuo Chen (陳昌倬) <czchen@debian.org> not-needed upstream upstream, https://github.com/jqlang/jq/commit/b86ff49f46a4a37e5a8e75a140cb5fd6e1331384
CVE-2024-23337.patch Fix signed integer overflow in jvp_array_write and jvp_object_rehash "ChangZhuo Chen (陳昌倬)" no 2025-05-25
CVE-2025-48060.patch Fix heap buffer overflow when formatting an empty string "ChangZhuo Chen (陳昌倬)" no 2025-07-08
CVE-2026-33947.patch CVE-2026-33947 "ChangZhuo Chen (陳昌倬)" no https://github.com/jqlang/jq/commit/fb59f1491058d58bdc3e8dd28f1773d1ac690a1f 2026-04-17
CVE-2026-33948.patch CVE-2026-33948 "ChangZhuo Chen (陳昌倬)" no https://github.com/jqlang/jq/commit/6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b 2026-04-17
CVE-2026-39956.patch CVE-2026-39956 "ChangZhuo Chen (陳昌倬)" no https://github.com/jqlang/jq/commit/fdf8ef0f0810e3d365cdd5160de43db46f57ed03 2026-04-17
CVE-2026-39979.patch CVE-2026-39979 "ChangZhuo Chen (陳昌倬)" no https://github.com/jqlang/jq/commit/2f09060afab23fe9390cce7cb860b10416e1bf5f 2026-04-17
CVE-2026-40164.patch CVE-2026-40164 "ChangZhuo Chen (陳昌倬)" no https://github.com/jqlang/jq/commit/0c7d133c3c7e37c00b6d46b658a02244fdd3c784 2026-04-17
CVE-2026-41256.patch Fix NUL truncation in program files loaded with -f
This fixes CVE-2026-41256.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/5a015deae35d19e3ebbc65db6c157a80e76df738 2026-04-24
CVE-2026-41257.patch Fix signed-int overflow in `stack_reallocate`
This fixes CVE-2026-41257.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/01b3cded76daacbfddb7f8763700b0803bcb5c6f 2026-04-24
CVE-2026-43896.patch Limit recursive object merge depth to prevent stack overflow
This fixes CVE-2026-43896.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/532ccea6080ed6758f39fe9f6208a44b665023d2 2026-05-05
CVE-2026-43895.patch Reject embedded NUL bytes in module import paths
jq accepts embedded NUL bytes at the language level but resolves
module import paths through NUL-terminated C strings, so the path
validated by policy or audit code could differ from the on-disk
path jq actually opens. Pass jv through gen_import so the AST
preserves the original bytes, and reject embedded NULs in
validate_relpath.

This fixes CVE-2026-43895.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/9d223f153c3632a207fa071caaa6292da33ae361 2026-05-09
CVE-2026-44777.patch Detect circular module imports to prevent stack overflow
jq used to recurse without bound on mutual or self-referential
`import` declarations, exhausting the stack. Track each library's
load state with a `loading` flag set before its dependencies are
processed; a recursive reference to an in-progress library now
reports "circular import of X".

This fixes CVE-2026-44777.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/f58787c41835d9b17795730cb04925fdba25c71c 2026-05-11
CVE-2026-43894.patch Reject numeric literals longer than DEC_MAX_DIGITS (999999999)
A signed-int overflow in decNumber's D2U macro lets huge literals
write attacker-controlled bytes past a stack buffer. Cap the length
before calling decNumberFromString, and pre-slice long strings in
jv_dump_string_trunc so the resulting error message doesn't itself
allocate a multi-GiB buffer.

This fixes CVE-2026-43894.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/9761ceb7d6cc48c16b25f0ab1baaef0e701927e4 2026-05-06
CVE-2026-47770.patch Guard deep structural equality and comparison recursion (#3539)
jv_equal and jv_cmp overflows the C stack on deeply nested
input. Cap recursion at 10000 with -1 / INT_MIN sentinels;
operators that compose user expressions surface this as
"Equality check too deep" / "Comparison too deep".

This fixes CVE-2026-47770.		 Yu-Fu Fu <yufu@yfu.tw> no https://github.com/jqlang/jq/commit/7122866869960b55cea3646bc91334ef55787831 2026-05-22
CVE-2026-49839.patch Fix heap-buffer-overflow in raw file loading
When `jv_string_append_buf` overflows the string length limit,
it returns an invalid `jv`; `jv_load_file` then re-entered it
on the invalid value and overran the heap. Break out of the loop
once the value is invalid.

Fixes CVE-2026-49839.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/e987df0d463d85fd70825e042a082427e8275b86 2026-06-08
GHSA-ggc9-rpv2-xgpm_and_GHSA-gvwx-xj9r-3frq.patch Fix undefined pointer arithmetic in UTF-8 helpers
Fixes GHSA-ggc9-rpv2-xgpm and GHSA-gvwx-xj9r-3frq.		 theyoucheng <daniel1988xyz@gmail.com> no https://github.com/jqlang/jq/commit/df924eae91af10cc236a907cdadd97813827aa1f 2026-05-23
CVE-2026-32316.patch Fix heap buffer overflow in `jvp_string_append` and `jvp_string_copy_replace_bad`

In `jvp_string_append`, the allocation size `(currlen + len) * 2` could
overflow `uint32_t` when `currlen + len` exceeds `INT_MAX`, causing a small
allocation followed by a large `memcpy`.

In `jvp_string_copy_replace_bad`, the output buffer size calculation
`length * 3 + 1` could overflow `uint32_t`, again resulting in a small
allocation followed by a large write.

Add overflow checks to both functions to return an error for strings
that would exceed `INT_MAX` in length. Fixes CVE-2026-32316.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/e47e56d226519635768e6aab2f38f0ab037c09e5 2026-03-12
CVE-2026-54679.patch Tighten string length bounds and propagate invalid jv in implode
The bound added in CVE-2026-32316 (e47e56d22) still allowed
`sizeof(jvp_string) + (currlen + len) * 2 + 1` to wrap `size_t` on
32-bit platforms. Tighten the threshold so the final allocation
fits in 32-bit `size_t`.

Also break out of `jv_string_implode` and `f_string_implode` once
`jv_string_append_codepoint` returns an invalid `jv`; otherwise the
next iteration triggers the assertion in `jvp_string_ptr` (or
invokes undefined behavior under `-DNDEBUG`).

Fixes CVE-2026-54679.		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/46d1da30944ce93dd671ac72b6513fc0eb747837 2026-06-16
CVE-2026-40612.patch Limit the containment check depth
This fixes CVE-2026-40612.

(cherry picked from commit d1a12569d91641135976a8536776a4a329c02cc2)

[Rebased for 1.7.1: the two upstream regression tests were reparenthesised as
"(reduce ...) as $x" because the jq 1.7 grammar only accepts a Term before
"as", unlike the 1.8 grammar used upstream.]		 itchyny <itchyny@cybozu.co.jp> no https://github.com/jqlang/jq/commit/d1a12569d91641135976a8536776a4a329c02cc2 2026-04-24
GHSA-gf4g-95wj-4q4r.patch Fix use-after-free in args2obj() array argument path (#3498)
Copy `kk` and `vk` before passing to jv_object_get(), which consumes
its arguments. Without copies, subsequent loop iterations read freed
memory (CWE-416) and post-loop jv_free() double-frees (CWE-415).

This bug was introduced in `b279713e` when array processing was hoisted
out of the loop into locals without accounting for jv_object_get()
semantics.

Fixes GHSA-gf4g-95wj-4q4r. No CVE has been assigned. Reachable through
the public libjq jq_compile_args() API when it is passed an array of
{"name":..,"value":..} objects; the jq CLI itself always passes an
object, which returns early, so the jq binary is not affected.		 Scott Seal <seal.scottm@gmail.com> no https://github.com/jqlang/jq/commit/3985b80ce50bd75c6eb5a97cb3348c3f835ca8e0 2026-03-09
fix-abort-on-string-repeat-overflow.patch Do not abort when a string repetition exceeds the length bound The fix for CVE-2026-32316 made jvp_string_append() return an invalid jv
once the result would exceed INT_MAX, where it had previously always
returned a valid string. binop_multiply() repeats a string by appending in
a loop and never checked the result, so the iteration after the bound was
reached passed an invalid jv to jvp_string_ptr(), which asserts:
.
$ echo '{"s":"abc","n":1000000000}' | jq '.s * .n'
jq: src/jv.c:1093: jvp_string_ptr: Assertion `JVP_HAS_KIND(a, JV_KIND_STRING)' failed.
Aborted
.
Both operands are ordinary data, so any filter that multiplies a string by
a number can be driven into the abort by its input. 1.7.1-6+deb13u2 returns
the repeated string here, so this is a regression introduced by the
CVE-2026-32316 backport rather than a pre-existing defect.
.
The same statement also passed alen * n to jv_string_empty(), which takes an
int, so the size of the initial allocation was computed by a conversion that
overflowed. Both problems are addressed by rejecting the operation up front
when the result cannot fit, and by stopping the loop if the append fails
anyway -- jvp_string_append() applies a slightly lower bound than INT_MAX
(it subtracts the string header), and that exact bound is private to jv.c.
.
Upstream fixed this in 1.8.0 by rewriting the repetition around a new
jv_string_repeat() function. That is not backported here because
jv_string_repeat is an exported symbol and adding it would extend the
libjq1 ABI surface in a stable update. The error message is kept identical
to the one upstream produces for this case.

===================================================================		 Aron Xu <aron@debian.org> not-needed 2026-08-05
fix-invalid-jv-propagation.patch Propagate invalid jv instead of aborting on it Several fixes in this series made functions that had always returned a valid
jv able to return an invalid one: jvp_string_append() and
jvp_string_copy_replace_bad() (CVE-2026-32316, CVE-2026-54679) and jv_sort()
(CVE-2026-47770). Callers written against the old contract feed the invalid
value straight back into an accessor, which asserts:
.
$ jq -n '(reduce range(10000) as $i ([];[.])) as $x
| null | delpaths([[$x],[$x]])'
jq: src/jv.c:986: jv_array_length: Assertion `JVP_HAS_KIND(j, JV_KIND_ARRAY)' failed.
.
$ head -c 360000000 /dev/zero | tr '\0' "'" > big.txt
$ jq -Rr '@html|length' big.txt
jq: src/jv.c:1097: jvp_string_ptr: Assertion `JVP_HAS_KIND(a, JV_KIND_STRING)' failed.
.
The two cases differ. 1.7.1-6+deb13u2 answers the delpaths one correctly, so
that is a regression this series introduces. On the @html one deb13u2 exits 0
but prints 12516352 where the answer is 2160000000 -- it is the CVE-2026-32316
integer overflow itself, so the abort is the fix landing without a graceful
error path rather than lost functionality. Both are addressed here.
.
Rather than guard each of the append loops in builtin.c (@base64, @csv, @tsv,
@sh, @uri, escape_string) separately, the check goes into jvp_string_append()
and jv_string_concat(), which every one of them funnels through. That also
covers call sites not reached during review. jv_string_concat() needs both
sides checked because it evaluates jv_string_value(b) before appending.
.
Guarding the string path then relocates the abort into error reporting:
jv_dump_string_trunc() only pre-truncates strings, so dumping a large array
or object for a type-error message returns invalid. Same for the three
jv_dump_string() results printed by main.c. deb13u2 reports these cleanly, so
they are regressions too and are guarded here.
.
Upstream 1.8.2 aborts identically on the delpaths, error-message and @html
cases, so there is nothing to cherry-pick.

===================================================================		 Aron Xu <aron@debian.org> no 2026-08-06

All known versions for source package 'jq'

Links