Bug#1135411: jackson-core: fixes for #1135411, #1148826 and the CVE-2025-52999 backport

[Juan Manuel Méndez Rey]

Hi,

I reassigned #1135411 to jackson-core: it comes from CVE-2025-52999.patch
(https://security-tracker.debian.org/tracker/CVE-2025-52999), which
backports the 2.15 number parsing but not the inLongRange() check from
https://github.com/FasterXML/jackson-core/pull/865. Since then every
integer with 19 digits, Long.MIN_VALUE and Long.MAX_VALUE included, fails
with "Numeric value (...) out of range of long". The build skips the
tests, so nobody noticed.

While fixing it I found that the same backport has two more gaps:

- Limits set on a JsonFactory are ignored; the parsers always use the
  defaults.
- The async parser does not enforce maxNumberLength. That is
  CVE-2026-18401 and its follow-up CVE-2026-68494
  (https://security-tracker.debian.org/tracker/CVE-2026-18401,
  https://security-tracker.debian.org/tracker/CVE-2026-68494). The
  tracker marks jackson-core not affected because upstream 2.14.1 has no
  number length limit, but Debian's 2.14.1-2 does, from the
  CVE-2025-52999 backport, and its async parser accepts over-long
  numbers. I checked that in unstable.

And #1148826 (CVE-2026-89425,
https://security-tracker.debian.org/tracker/CVE-2026-89425) affects
2.14.1 as well: the DataInput parser reads the whole invalid token into
the error message, so a large one runs out of memory.

One merge request fixes all of it, each as its own patch backported from
upstream: https://salsa.debian.org/java-team/jackson-core/-/merge_requests/8
With it and the jackson-databind fix for #1139511, jackson-modules-java8
builds again and its tests pass.

trixie (2.14.1-2~deb13u1) and bookworm (2.14.1-2~deb12u1) carry the same
patch, so they should have the same problems at run time (I tested
unstable only). Copying the security team for that.

Thanks,
Juan