Add an advisory for 2026-09-29

Change-Id: I0e8087d747ead119486e968e29017d766a6a6964
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/103347
Commit-Queue: Lily Chen <chlily@google.com>
Reviewed-by: Xiangfei Ding <xfding@google.com>

docs/advisories/2026-09-29.md

@@ -0,0 +1,60 @@
+# OpenSSL Advisory: September 29, 2026
+
+OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20260929.txt). Here's how it affects BoringSSL:
+
+CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL
+----|---------|-----------------------|---------------------
+CVE-2026-84782 | DTLS Retransmits Handshake Messages From a Stale Buffer Offset | High | Not affected, BoringSSL [fixed this in 2016](https://boringssl-review.googlesource.com/c/boringssl/+/8433) as part of independent cleanup
+CVE-2026-84783 | Use-After-Free in X.509 Extension Cache Under Concurrent Use | Moderate | Not affected, issue was introduced after fork
+CVE-2026-35189 | Excessive Memory Allocation in Relative CRLDP Processing | Low | **Affected, see discussion below**
+CVE-2026-35191 | QUIC Unvalidated Amplification Credit may be Over Accounted | Low | Not affected, issue was introduced after fork
+CVE-2026-42772 | Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC | Low | Not affected, issue was introduced after fork
+CVE-2026-54872 | Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves | Low | Not affected, BoringSSL independently [fixed this in 2017](https://boringssl-review.googlesource.com/c/boringssl/+/23075)
+CVE-2026-54873 | QUIC STREAM Fragment Metadata DoS | Low | Not affected, issue was introduced after fork
+CVE-2026-54875 | Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V | Low | Not affected, issue was introduced after fork
+CVE-2026-72897 | Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake | Low | Not affected, issue was introduced after fork
+CVE-2026-75804 | QUIC Connection-Level Flow Control is Not Enforced for Streams | Low | Not affected, issue was introduced after fork
+CVE-2026-75805 | NULL Pointer Dereference in CMP Client Revocation Response Handling | Low | Not affected, issue was introduced after fork
+CVE-2026-75806 | Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS | Low | Not affected, issue was introduced after fork
+CVE-2026-77696 | Timing Side-Channel in SM2 Signature Generation | Low | Not affected, issue was introduced after fork
+CVE-2026-84784 | QUIC: Unbounded RETIRE_CONNECTION_ID Backlog | Low | Not affected, issue was introduced after fork
+
+[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity
+
+## CVE-2026-35189
+
+BoringSSL is impacted by this issue. Impacted callers should update to [9b639f5b3b086508c03f6a4a1792e4a6043777ac](https://boringssl.googlesource.com/boringssl/+/9b639f5b3b086508c03f6a4a1792e4a6043777ac) or later. This change is included in release [0.20260929.0](https://boringssl.googlesource.com/boringssl/+/refs/tags/0.20260929.0) ([BCR](https://registry.bazel.build/modules/boringssl/0.20260929.0)) or later.
+
+The bug is triggered by the obscure `nameRelativeToCRLIssuer` feature in X.509 CRL distribution points. While CRL distribution points are typically URLs, X.509 was originally designed to provide a [directory service](https://en.wikipedia.org/wiki/X.500) and supports a wide range of now unused CRL distribution point formats. This particular one was discouraged by [RFC 5280](https://www.rfc-editor.org/info/rfc5280/) in 2008:
+
+> Conforming CAs SHOULD NOT use nameRelativeToCRLIssuer to specify distribution point names.
+
+OpenSSL's `nameRelativeToCRLIssuer` eagerly computed the absolute distribution point name when the implementation computes ["cached extensions"](https://crbug.com/443261873). A single certificate can have multiple distribution points, so this can can trigger quadratically-scaled memory allocation when [cached extensions](https://crbug.com/443261873) are filled in. This can result in a denial of service.
+
+The fix in BoringSSL removes `nameRelativeToCRLIssuer` support altogether. We had independently planned to [remove this feature](https://crbug.com/42290571), but had not yet done so. Distribution points that use `nameRelativeToCRLIssuer` will be ignored.
+
+The issue only triggers when cached extensions are computed, so not all callers that construct `X509` objects are impacted. Cached extensions are primarily computed during certificate verification. This impacts callers that:
+
+* Verify server certificates as a TLS client.
+* Request and verify client certificates as a TLS server.
+* Use `X509_verify_cert`.
+
+Callers are also impacted if they use any of the following symbols:
+
+* `X509_get_extension_flags`
+* `X509_get_key_usage`
+* `X509_get_extended_key_usage`
+* `X509_get0_subject_key_id`
+* `X509_get0_authority_key_id`
+* `X509_get0_authority_issuer`
+* `X509_get0_authority_serial`
+* `X509_get_pathlen`
+* `X509_cmp`
+* `CMS_USE_KEYID`
+* `PKCS7_sign`
+* `X509_check_purpose`
+* `X509_check_ca`
+* `X509_check_issued`
+* `X509_check_trust`
+
+Callers that meet the above criteria and who are sensitive to DoS should update to a fixed version of BoringSSL.