HASH HAL missing NULL pointer validation in HAL_HASH_Start_IT leads to crash (CWE-20)

[karnakarreddi]

Summary

HAL_HASH_Start_IT() does not validate pInBuffer before storing and later dereferencing it in interrupt-driven processing. Passing a NULL input buffer with a non-zero size can trigger a hard fault / crash.

This appears to be an improper input validation issue (CWE-20).

Affected Function

trusted-firmware-m/platform/ext/target/stm/common/stm32u3xx/hal/Src/stm32u3xx_hal_hash.c

Line 933 in 2b37dce

HAL_StatusTypeDef HAL_HASH_Start_IT(HASH_HandleTypeDef *hhash, const uint8_t *const pInBuffer, uint32_t Size,

HAL_StatusTypeDef HAL_HASH_Start_IT(
HASH_HandleTypeDef *hhash,
const uint8_t *const pInBuffer,
uint32_t Size,
uint8_t *const pOutBuffer)
Root Cause

HAL_HASH_Start_IT() validates hhash but does not validate pInBuffer.

Relevant code:

if (hhash == NULL)
{
return HAL_ERROR;
}

hhash->pHashInBuffPtr = pInBuffer;

The pointer is later dereferenced in HASH_WriteData_IT() without validation:

__IO uint32_t inputaddr = (uint32_t)(hhash->pHashInBuffPtr);

hhash->Instance->DIN = *(uint32_t *)inputaddr;

If:

pInBuffer == NULL
Size > 0

then the code dereferences address 0x0, which can result in a hard fault or system crash.

Impact

This can cause denial of service via crash/hard fault when invalid parameters reach the HAL API.

Because the operation is interrupt-driven, the invalid pointer is stored in the handle state and later consumed asynchronously.

Reproduction

Example:

HAL_HASH_Start_IT(&hhash, NULL, 32, output);

This eventually reaches:

*(uint32_t *)0

inside HASH_WriteData_IT().

Suggested Fix

Validate pointer/size combinations before enabling interrupts or storing the pointers.

Example:

if ((hhash == NULL) ||
((pInBuffer == NULL) && (Size > 0U)) ||
(pOutBuffer == NULL))
{
return HAL_ERROR;
}

At minimum:

if ((pInBuffer == NULL) && (Size > 0U))
{
return HAL_ERROR;
}

[nicola-mazzucato-arm]

Thank you @karnakarreddi for sharing this finding.
Can you please submit a patch for review in https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/ so that the platform maintainers can take this further?
Please refer to this issue in the commit message for proper tracking.
Best regards
Nick

[MJASTM]

Thank you for the report. I agree with the general observation.

That said, the proposed change does not appear to be specific to HAL_HASH_Start_IT(), as the same pattern can be found in most of the functions in this file. More broadly, although this code is present in TF-M, it originates from the ST HAL drivers and is not maintained directly by the TF-M team.

I also checked equivalent HASH HAL implementations in other STM32 families and found the same pattern there as well. This suggests that, in the current implementation of these HAL HASH APIs, input/output buffer pointer validity is not checked systematically and is therefore expected to be ensured by the caller.

If you believe this behavior should be changed in the HAL implementation, the preferred path would be to report it directly in the relevant STM32 HAL GitHub repository:

STM32U3 HAL GitHub repository

This would also ensure that, when TF-M later updates the imported HAL sources, it can benefit from the fix as part of the regular HAL synchronization process.

Best regards,
Marc

[karnakarreddi]

Thanks both — and thanks @MJASTM for the context on provenance.
Agreed. Since stm32u3xx_hal_hash.c is imported from the ST HAL and the same pattern spans the whole file (and other STM32 families), the right fix is upstream rather than a local TF-M divergence that would be lost at the next HAL sync. I'll open an issue/PR against the STM32U3 HAL repo and reference this issue there for tracking.
To frame it accurately upstream, I'll position it as a defensive NULL/size hardening check rather than an exploitable DoS, since the HAL sits below the PSA input-validation boundary and an invalid pInBuffer can only originate from secure-world caller code.
Happy to keep this open for tracking until the fix lands upstream and is pulled in via sync — or close it now and I'll link the upstream PR back here once it's up, whichever you prefer.