Page MenuHomeFreeBSD

aesni: Avoid a potential out-of-bounds load in AES_GCM_encrypt()
ClosedPublic

Authored by markj on Nov 16 2021, 2:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 4, 4:36 AM
Unknown Object (File)
Mon, Nov 4, 4:36 AM
Unknown Object (File)
Mon, Nov 4, 4:36 AM
Unknown Object (File)
Mon, Nov 4, 4:35 AM
Unknown Object (File)
Mon, Nov 4, 4:17 AM
Unknown Object (File)
Sun, Oct 20, 1:10 PM
Unknown Object (File)
Sun, Oct 13, 12:03 PM
Unknown Object (File)
Oct 9 2024, 12:43 PM
Subscribers

Details

Summary

This is effectively the same problem as the one fixed in 564b6aa7fccd
("aesni: Avoid a potential out-of-bounds load in aes_encrypt_icm()")
but I didn't have a reproducer before.

Reported by: Jenkins

Test Plan

The ktls tests trigger this when KASAN is enabled. With this
change they pass. cryptocheck -d aesni0 -z -a aes-gcm{,192,256} also
runs successfully.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Nov 16 2021, 2:17 PM
cem added inline comments.
sys/crypto/aesni/aesni_ghash.c
510

Can we not use _mm_xor_si128(tmp1, last_block)? Or we assume ^ generates the same instruction?

This revision is now accepted and ready to land.Nov 16 2021, 3:19 PM
markj added inline comments.
sys/crypto/aesni/aesni_ghash.c
510

The aesni code does both but we should stay consistent within this function, I'll switch to the intrinsic.

markj marked an inline comment as done.

Use the xor intrinsic

This revision now requires review to proceed.Nov 16 2021, 3:44 PM
This revision is now accepted and ready to land.Nov 16 2021, 4:20 PM