Control: tags -1 + fixed-upstream patch

Hi,

CVE-2026-85495 (GHSA-frhv-j822-2pvx) is fixed upstream in ppp 2.5.4. The
fix is two commits:

https://www.google.com/url?q=https://github.com/ppp-project/ppp/commit/cc8b00c966&source=gmail&ust=1793768092008000&sa=E
"pppd: Protect against receiving duplicate configuration options (#611)"
(touches ccp.c, ipcp.c, ipv6cp.c, lcp.c, lcp.h)

https://www.google.com/url?q=https://github.com/ppp-project/ppp/commit/1baf2ac29e&source=gmail&ust=1793768092008000&sa=E
"pppd: Guard writes to nak_buffer in lcp_reqci (#623)"
(touches lcp.c; depends on the seenci[] logic from cc8b00c966)

Backport onto the Debian 2.5.2-1+2 source, with debian/patches applied:
- The cc8b00c966 changes to lcp.c, lcp.h, ccp.c and ipv6cp.c apply
cleanly.
- Two ipcp.c hunks need trivial manual rebasing. One fails only because
Debian's line after "BZERO(ho, sizeof(*ho));" has trailing whitespace.
The other is the removal of the "ho->neg_addr = 1;" line in the
CI_ADDR case, which sits on different context in 2.5.2.
- 1baf2ac29e then applies on top with offsets only.
The resulting lcp.c is identical to upstream's, apart from the unrelated
option-limit changes in 0bf7647f1d, which I deliberately left out. I can
send the combined diff (about 115 changed lines) if useful.

Testing:
- Built with -fsanitize=address,undefined. Two build notes: it needs
-std=gnu17 with current GCC because of the K&R getspnam() declaration
in pppd/session.c, and the optional TLS/PAM/pcap/plugins were disabled
for this test build. No compiler warnings from the backport.
- Ran upstream's 2.5.4 integration testsuite (testsuite/ + runtests.py:
pppd pairs in private network namespaces) against both builds:
2.5.2-1+2 unpatched: 7/7 pass
with backport: 7/7 pass, no ASan/UBSan reports
The tests are version, auth-pap, auth-chap, link-up, mtu-negotiation,
ping and data-transfer, so LCP/IPCP negotiation and authentication are
unaffected.

I did not reproduce the overflow itself. This verifies only that the
backport applies and builds and that normal negotiation still works.

Thanks!

Reply via email to