…3029)

### Issues:
Addresses #3028 

### Description of changes:
When GCC 15 compiles the FIPS module at `-O3` on aarch64, it emits
`fmov` instructions with floating-point immediates (e.g. `fmov v8.4s,
#2.0e+0`). The delocator's PEG grammar only supports integer immediates,
so it parses `#2.0e+0` as the integer `#2` followed by what it thinks is
a symbol reference `.0e`. This gets turned into a redirector
(`.Lbcm_redirector_.0e`), producing invalid assembly.

This change fixes the issue in two ways:
- **Grammar fix**: Adds a floating-point immediate alternative to the
`RegisterOrConstant` rule in `delocate.peg`, so values like `#2.0e+0`
are parsed as a single token.
- **Pass-through**: Adds `fmov` to the special-case instruction list in
`processAarch64Instruction()`. Since `fmov` only operates on registers
and immediates (never memory), it never needs delocating and can safely
be written through unchanged.

The GCC 15 + FIPS exclusion in `arm-gcc-tests` CI is also removed now
that the underlying issue is resolved.

### Call-outs:
The `delocate.peg.go` file is regenerated from the grammar using the
`peg` tool. The grammar change is the one line in `delocate.peg`; the
rest of that file is mechanical.

### Testing:
- Added 6 test cases to `testdata/aarch64-Basic/in.s` covering float
immediates with exponent notation, simple decimals, negative values,
fractional values, scalar forms, and register-to-register `fmov`.
- All 19 existing delocator tests continue to pass.
- Re-enabled the `arm-gcc-tests` CI matrix entry for GCC 15 + FIPS on
arm64 which will validate the end-to-end build.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Hello team! I noticed the issue while investigating potential adoption.
The porting guide refactor in #1463
missed this.

I also took the liberty of splitting the affected run-on sentence.

---

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Co-authored-by: Justin W Smith <103147162+justsmth@users.noreply.github.com>
Co-authored-by: Nevine Ebeid <66388554+nebeid@users.noreply.github.com>

…#3044)

### Description of changes:
Two small fixes in `crypto/x509/x509_vfy.c`:

1. In `internal_verify`, the post-loop leaf public key check was setting
`ctx->current_cert = xi` (the issuer) instead of `xs` (the subject). The
chain was still correctly rejected — just the diagnostic metadata
pointed at the wrong cert. Fixed to `xs`.

2. Added a comment explaining why the EC explicit params check in
`check_chain_extensions` intentionally skips single-cert chains (`num >
1`). This matches OpenSSL 1.1.1 behavior and is fine because single-cert
chains are already in the trust store. No behavioral change.

### Call-outs:
Neither issue is a security vulnerability. One is a one-line code fix,
the other is comment-only.

### Testing:
All existing X509 tests pass. `X509Test.SignatureVerification` and
`X509CompatTest.LeafCertificateWithExplicitECParams` both cover the
relevant code paths.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

### Description of changes: 
`check_custom_critical_extensions` previously cleared the
`EXFLAG_CRITICAL` bit from a certificate's cached `ex_flags `after
successfully validating custom critical extensions. The original intent
was to record that the certificate's critical extensions had been
handled, preserving that outcome for the certificate going forward.
However, custom critical extension validation is a property of the
verification context, not the certificate itself. This change removes
the flag clearing so that the custom extension check is evaluated during
each verification rather than permanently mutated on the `cert`. This
ensures that re-verifying the same `X509` object without a custom
callback correctly reports
`X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION`.

### Call-outs:
N/A

### Testing:
Tweak and add minor test that checks the behavior.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Update ACVP documentation with new configuration support.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

### Description of changes: 
AWS-LC provides no-op stub implementations of several OpenSSL `UI_xxx`
functions to allow compilation of projects that reference them for
non-essential operations. These stubs always fail at runtime since the
UI API is unsupported.

Previously, `UI_add_input_string`, `UI_add_verify_string`,
`UI_add_info_string`, and `UI_process` all returned `0`. In OpenSSL's UI
API, `-1` indicates failure:

- `UI_add_input_string`, `UI_add_verify_string`, and
`UI_add_info_string` all delegate to
[`general_allocate_string()`](https://github.com/openssl/openssl/blob/06cff36e641c39f1859f78adcf20d0d977ea0088/crypto/ui/ui_lib.c#L118),
which returns a positive index on success and `-1` on error.
-
[`UI_process`](https://github.com/openssl/openssl/blob/06cff36e641c39f1859f78adcf20d0d977ea0088/crypto/ui/ui_lib.c#L327)
returns `0` on success and `-1` on error.

In practice, callers should already be checking the `NULL` return from
`UI_new` and never reaching these functions. This change simply corrects
the return values to be consistent with the OpenSSL API contract, and
updates the corresponding header documentation to match.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

### Description of changes:
The `PQDSA_KEY` setter functions could leave the key structure in an
inconsistent state where stale fields no longer corresponded to the
current key material.

- `PQDSA_KEY_set_raw_private_key`: Did not clear `key->seed` on success.
If the key previously held a seed (or had an uninitialized seed buffer
from `PQDSA_KEY_init`), `pqdsa_priv_encode` would serialize stale or
uninitialized seed bytes, since it gates on `key->seed != NULL`.
- `PQDSA_KEY_init`: Used `OPENSSL_malloc` (uninitialized) for all three
buffers. Changed to `OPENSSL_zalloc` as a defense-in-depth measure.
- `PQDSA_KEY_get0_dsa`: Added a NULL check on the input, consistent with
other functions in this file.

### Call-outs:
The primary fix is in `PQDSA_KEY_set_raw_private_key`. Current code
paths through the public API are not affected because
`EVP_PKEY_pqdsa_set_params` uses `PQDSA_KEY_new` (which zero-initializes
all fields), but these functions are exposed via `internal.h` and the
inconsistency could be triggered by internal callers.

Separately, `pqdsa_priv_decode` currently ignores the `pubkey` parameter
from `OneAsymmetricKey`, unlike the Ed25519 implementation which
validates the provided public key against the derived one. This could be
addressed as a follow-up.

### Testing:
All existing ML-DSA/PQDSA tests pass (76 tests).

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Prepare release AWS-LC v1.69.0

Ensure all signer certificate chains are verified.

Use CRYPTO_memcmp instead of OPENSSL_memcmp for tag verification.

…s fails (#3061)

Return correct error value when parsing PKCS7 authenticated attributes fails.