Skip to content

Improve type safety and bounds checking in EVP cipher ctrl handlers#3034

Merged
justsmth merged 2 commits intoaws:mainfrom
justsmth:fix-ccm-iv-length
Mar 6, 2026
Merged

Improve type safety and bounds checking in EVP cipher ctrl handlers#3034
justsmth merged 2 commits intoaws:mainfrom
justsmth:fix-ccm-iv-length

Conversation

@justsmth
Copy link
Contributor

Description of changes:

Fixes minor correctness and safety issues in the AES-GCM and AES-CCM EVP cipher ctrl handlers:

  • e_aes.c (EVP_CTRL_GCM_SET_IV_INV): Added bounds validation for arg (arg <= 0 || arg > gctx->ivlen). The companion handler EVP_CTRL_GCM_IV_GEN already validates arg before the same gctx->iv + gctx->ivlen - arg pointer arithmetic, but SET_IV_INV did not, allowing potential out-of-bounds access from a misuse of the API.
  • e_aesccm.c
    • EVP_CTRL_GET_IVLEN: The handler wrote through a uint32_t * cast, but the caller in EVP_CIPHER_CTX_iv_length passes an int *. This is a strict aliasing violation. Changed to *(int *)ptr to match the caller and the GCM handler's convention.
    • CCM_L_TO_NONCE_LEN macro: Added parentheses around the macro parameter to follow standard C macro hygiene.

Call-outs:

The uint32_t * vs int * mismatch is undefined behavior under C strict aliasing rules, though it is unlikely to cause issues in practice since both types are 32 bits on almost all platforms. The other two changes are defensive hardening.

Testing:

Existing tests cover these code paths. No behavioral change is expected for valid inputs.

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.

@codecov-commenter
Copy link

codecov-commenter commented Feb 24, 2026

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 78.37%. Comparing base (e2b4850) to head (984c634).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
crypto/fipsmodule/cipher/e_aes.c 50.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3034      +/-   ##
==========================================
- Coverage   78.37%   78.37%   -0.01%     
==========================================
  Files         689      689              
  Lines      121148   121150       +2     
  Branches    16973    16973              
==========================================
- Hits        94948    94946       -2     
- Misses      25302    25308       +6     
+ Partials      898      896       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@justsmth justsmth merged commit 48040c6 into aws:main Mar 6, 2026
443 of 455 checks passed
@justsmth justsmth deleted the fix-ccm-iv-length branch March 6, 2026 21:01
WillChilds-Klein pushed a commit to WillChilds-Klein/aws-lc that referenced this pull request Mar 11, 2026
…ws#3034)

### Description of changes:
Fixes minor correctness and safety issues in the AES-GCM and AES-CCM EVP
cipher ctrl handlers:

- **`e_aes.c` (`EVP_CTRL_GCM_SET_IV_INV`):** Added bounds validation for
`arg` (`arg <= 0 || arg > gctx->ivlen`). The companion handler
`EVP_CTRL_GCM_IV_GEN` already validates `arg` before the same `gctx->iv
+ gctx->ivlen - arg` pointer arithmetic, but `SET_IV_INV` did not,
allowing potential out-of-bounds access from a misuse of the API.
- **`e_aesccm.c`** 
- **`EVP_CTRL_GET_IVLEN`:** The handler wrote through a `uint32_t *`
cast, but the caller in `EVP_CIPHER_CTX_iv_length` passes an `int *`.
This is a strict aliasing violation. Changed to `*(int *)ptr` to match
the caller and the GCM handler's convention.
- **`CCM_L_TO_NONCE_LEN` macro:** Added parentheses around the macro
parameter to follow standard C macro hygiene.

### Call-outs:
The `uint32_t *` vs `int *` mismatch is undefined behavior under C
strict aliasing rules, though it is unlikely to cause issues in practice
since both types are 32 bits on almost all platforms. The other two
changes are defensive hardening.

### Testing:
Existing tests cover these code paths. No behavioral change is expected
for valid inputs.

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: Sanketh Menda <sgmenda@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants