Control: tags 1151100 + patch Control: tags 1151102 + patch Hi Josue,
Attached is a debdiff for a 1.3.7+ds-1.1 NMU fixing both bugs. I have
not uploaded anything; please use as much or as little of it as you like.
It adds four patches after 00-fix-missing-symbols-gen.diff:
pmaplist-free-use-after-free.patch upstream 9c15036c
CVE-2026-85977.patch upstream ccc1acf8 (#1151102)
CVE-2026-85231.patch upstream 65d27459 (#1151100)
CVE-2026-85231-privacy.patch mine, see below
Notes:
- 9c15036c ("Fix use-after-free in xdr_pmaplist() XDR_FREE path") is
not mentioned in the tracker, but it lands in 1.3.8 right before the
CVE-2026-85977 fix and is needed: with 1.3.7+ds-1, xdr_free() of any
decoded pmaplist segfaults here (even a normal 500-entry list), and
the new node limit makes failed partial decodes, which take that free
path, routine.
- Upstream's CVE-2026-85231 fix is incomplete, also in the released
1.3.8: the commit message says it bounds all three decode calls in
xdr_rpc_gss_unwrap_data(), but it only changes databody_integ and the
checksum. The databody_priv decode still passes (u_int)-1, and the
CVE explicitly covers integrity and privacy. CVE-2026-85231-privacy.patch
applies the same RPCSEC_GSS_MAX_UNWRAP bound there (one line,
Forwarded: no). It probably deserves a separate CVE or an upstream
follow-up; I have not reported it upstream yet.
Testing (sid chroot, amd64), using the public XDR entry points on
in-memory buffers rather than a network setup:
- xdr_rpc_gss_data() decode with a length field of 0xF0000000 and no
data, under RLIMIT_AS 256 MB ("xdr_bytes: out of memory" means the
claimed size was allocated before any check):
1.3.7+ds-1: integ allocates, priv allocates
+ upstream patches only: integ bounded, priv allocates
1.3.7+ds-1.1 (all four): integ bounded, priv bounded
- xdr_pmaplist() decode of a PMAPPROC_DUMP body, then xdr_free():
1.3.7+ds-1: 3,000,000 nodes accepted (about 137 MB of heap);
xdr_free() segfaults for 500 and 3,000,000 nodes
1.3.7+ds-1.1: 500 and 1024 nodes decode and free normally;
3,000,000 is rejected after 1024 nodes and freed cleanly
- The same stock results reproduce against the installed 1.3.7+ds-1
binary package.
- lintian: source tags identical to 1.3.7+ds-1; nothing new related to
the change. The package has no upstream test suite.
- The upstream commits were taken from
https://www.google.com/url?q=http://git.linux-nfs.org&source=gmail&ust=1793554863435000&sa=E
(steved/libtirpc) and checked by full commit id; all are in the
libtirpc-1-3-8 tag. The INSTALL hunk of 9c15036c (an automake
symlink change) is dropped.
Thanks!
Regards,
automationcanadian
libtirpc_1.3.7+ds-1.1.debdiff.gz
Description: GNU Zip compressed data
