Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
When using CHIPCryptoPALPSA, I encountered a case where the plaintext buffer size is not large enough.
When calling AES_CCM_decrypt from HandleSigma3a, the input and ouput buffer are the same location:
In my case, ciphertext_length is equal to 0x226, so when calling psa_aead_update, the output size is computed with PSA_AEAD_UPDATE_OUTPUT_SIZE macro, which rounds up 0x226 to 0x230.
This is a problem, because the output buffer is the input buffer, so its size is 0x226.
Here is the context in psa_aead_update:
There is a risk of buffer overflow.
Bug prevalence
whenever the input length is not a multiple of a block size
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Remove stale label or comment or this will be closed in 30 days.
Reproduction steps
When using
CHIPCryptoPALPSA
, I encountered a case where theplaintext
buffer size is not large enough. When callingAES_CCM_decrypt
fromHandleSigma3a
, the input and ouput buffer are the same location:In my case,
ciphertext_length
is equal to0x226
, so when callingpsa_aead_update
, the output size is computed withPSA_AEAD_UPDATE_OUTPUT_SIZE
macro, which rounds up0x226
to0x230
. This is a problem, because the output buffer is the input buffer, so its size is0x226
. Here is the context inpsa_aead_update
:There is a risk of buffer overflow.
Bug prevalence
whenever the input length is not a multiple of a block size
GitHub hash of the SDK that was being used
ea01e21b18e54f6fedcd8c47b46c183a54ee3aea
Platform
core
Platform Version(s)
No response
Anything else?
No response