Hi all, I'm a returning contributor (former NM applicant eim, advocated in 2005, never finished the process, stepped away not long after) coming back to Debian. Raphael suggested I introduce myself here directly with real work rather than just asking questions, so here's where I actually am.
I don't have a Salsa account approved yet (request is still pending review), so I can't push branches or open MRs myself. Both packages below are fully backported, built, and tested against their real bookworm source - I'd appreciate a review, and help getting them uploaded, if someone has the time. == cjose (CVE-2026-53938, CVE-2026-53939) == Bookworm ships cjose 0.6.2.1-1, vulnerable to both. Two small patches, DEP-3 headers included, both verified: applied cleanly against the real 0.6.2.1-1 source, patched source builds, and I wrote a standalone reproduction confirming the actual bug on unpatched source and the fix on patched source (not just reading the commit messages). --- CVE-2026-53938.patch --- Description: fix heap buffer overflow in AES key unwrap _cjose_jwe_decrypt_ek_aes_kw() passed the attacker-controlled encrypted_key straight to AES_unwrap_key() without checking its length against the fixed-size jwe->cek buffer it unwraps into. A crafted JWE with an oversized encrypted_key segment for an AES key wrap algorithm (A128KW/A192KW/A256KW) triggers an out-of-bounds heap write, which is at minimum a remote, unauthenticated denial of service. Add the length check RFC 3394 already implies (wrapped key length is always the plaintext CEK length plus 8 bytes) before unwrapping. Origin: upstream, https://github.com/OpenIDC/cjose/commit/8c51d2452 Bug: https://github.com/OpenIDC/cjose/security/advisories Forwarded: not-needed Applied-Upstream: 0.6.2.5 --- a/src/jwe.c +++ b/src/jwe.c @@ -587,6 +587,15 @@ static bool _cjose_jwe_decrypt_ek_aes_kw(_jwe_int_recipient_t *recipient, cjose_ return false; } + // the wrapped key (RFC 3394) is always the plaintext CEK length plus 8 bytes; + // enforce this before calling AES_unwrap_key, which would otherwise copy the + // attacker-controlled encrypted_key into the fixed-size jwe->cek buffer + if (recipient->enc_key.raw_len != jwe->cek_len + 8) + { + CJOSE_ERROR(err, CJOSE_ERR_INVALID_ARG); + return false; + } + // AES unwrap the CEK in to jwe->cek int len = AES_unwrap_key(&akey, (const unsigned char *)NULL, jwe->cek, (const unsigned char *)recipient->enc_key.raw, recipient->enc_key.raw_len); --- CVE-2026-53939.patch --- Description: fix all-zero content-encryption key for AES-CBC-HMAC _cjose_jwe_set_cek_aes_cbc() passed the wrong boolean to _cjose_jwe_malloc()'s "zero" parameter (inverted), so a freshly generated CEK for AES-CBC-HMAC content encryption was always zero-filled instead of randomly generated. Every JWE produced with an AES-CBC-HMAC enc algorithm was therefore encrypted and authenticated under the same fixed, publicly known key, letting anyone who obtains such a JWE recover the plaintext and forge or modify the content. Origin: upstream, https://github.com/OpenIDC/cjose/commit/2a6e5bd96 Bug: https://github.com/OpenIDC/cjose/security/advisories Forwarded: not-needed Applied-Upstream: 0.6.2.6 (Full patch, changelog stanza, and dla-needed.txt claim note ready - happy to send whichever format is easiest to work with.) == git-lfs (CVE-2025-26625) == Bookworm ships git-lfs 3.3.0-1+deb12u1. git lfs checkout/pull wrote object content via os.Create(), which follows a symlink at the target path and truncates any hardlinked file in place instead of replacing it - a crafted repository can make either command write outside the working tree. Backported the full fix (not just the core issue): the write-path fix itself, plus the two follow-up hardening commits (checking intermediate path components for symlinks, and refusing to run against a bare repository). One real adaptation needed: bookworm's actual build toolchain is golang-1.19, which predates the stdlib errors.Join the upstream hardening commit relies on - worked around with a portable fmt.Errorf %w wrap instead, verified against upstream's own (unmodified) test file. Verified twice: incrementally, then again applying the full patch series from a pristine source extraction to confirm it works standalone. go build and go test both clean both times. These patches are larger (one of them touches a new file plus five existing ones) - I'll send them separately in whatever form's easiest, rather than paste ~800 lines here. Let me know what you need from me to move either of these forward. Thanks, Ivo
