Page MenuHomeFreeBSD

aesni: Fix yet another out-of-bounds read
ClosedPublic

Authored by markj on Dec 15 2021, 5:20 PM.
Tags
None
Referenced Files
F116828885: D33474.id100096.diff
Sat, May 10, 5:30 PM
Unknown Object (File)
Sat, May 10, 1:57 AM
Unknown Object (File)
Fri, May 9, 11:18 AM
Unknown Object (File)
Tue, May 6, 5:57 AM
Unknown Object (File)
Wed, Apr 23, 2:44 PM
Unknown Object (File)
Tue, Apr 15, 4:08 AM
Unknown Object (File)
Mon, Apr 14, 6:15 PM
Unknown Object (File)
Mon, Apr 14, 12:27 AM
Subscribers

Details

Summary

This is the same as 4285655adb74 ("aesni: Avoid a potential
out-of-bounds load in AES_GCM_encrypt()") except for the decryption
path. I failed to notice this last time since I assumed that encryption
and decryption use the same routine, like the CTR mode implementation
does.

Reported by: Jenkins (KASAN job)

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 43381
Build 40269: arc lint + arc unit

Event Timeline

markj requested review of this revision.Dec 15 2021, 5:20 PM

LGTM modulo overflow concern and what looks like a typo.

sys/crypto/aesni/aesni_ghash.c
793

Is this correct if nbytes was > 2GB? nbytes is a uint32 but resid is (signed) integer.

807

typo

sys/crypto/aesni/aesni_ghash.c
793

I think it still happens to work. Note that OCF itself can only describe buffers up to 2GB anyway (crp_payload_length is an int I think?)

markj marked 3 inline comments as done.

Drop the use of resid entirely, this is consistent with AES_GCM_encrypt() anyway.

This revision is now accepted and ready to land.Dec 15 2021, 8:03 PM