Skip to content

Fixes for integer truncation - #153

Open
ifranzki wants to merge 2 commits into
opencryptoki:masterfrom
ifranzki:cmac_fixes
Open

Fixes for integer truncation#153
ifranzki wants to merge 2 commits into
opencryptoki:masterfrom
ifranzki:cmac_fixes

Conversation

@ifranzki

@ifranzki ifranzki commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@ifranzki
ifranzki requested a review from vkanjur September 1, 2026 07:22
…ereference

Function check_cmac_parms() allows message to be NULL, if message_length is
zero. The callers of check_cmac_parms() supply a unsigned long message length
to check_cmac_parms() which truncates the length to an unsigned int.

If an unsigned long message length truncates to 0 as unsigned int (for
example 0x100000000UL) then a NULL message is accepted, although the
subsequent code operate on the non-zero unsigned long message length and
thus attempt to dereference the NULL message.

While at it fix a similar integer truncation with check_aes_parms(). There
it does not have any bad consequences, but it is still worth to fix.

Reported by: Aisle Research
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
…, not long

The caller of s390_ccm() passes an unsigned int mac length and nonce_length
to s390_ccm(). Furthermore s390_ccm() passes them to s390_ccm_authenticate()
which uses an unsigned int.

This mismatch does not produce a problem, because the value of mac_length
and nonce_length can anyway not be larger than unsigned int, because the
outer most caller has it as unsigned int.

Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.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.

1 participant