[Bug]: Integer overflow in SE050 hash update could mess up the heap

[zulfff]

Contact Details

arjunaajalahla100@gmail.com (pelioro)

Version

current branch

Description

Yo, found a sketchy integer overflow in the SE050 hash code. Check this out at wolfcrypt/src/port/nxp/se050_port.c around line 275:

if (se050Ctx->len < se050Ctx->used + len) {  // overflow could happen here
    tmp = XMALLOC(se050Ctx->used + len, ...);  // allocates less than expected
}
XMEMCPY(se050Ctx->msg + se050Ctx->used, data, len);  // writes too much

So basically if se050Ctx->used is like 4GB-ish (0xFFFFFFF0) and len is small, the addition wraps around and we allocate tiny buffer but copy full data = heap overflow city.

Suggested fix

Just slap an overflow check before the addition:

// Before line 275
if (se050Ctx->used > 0xFFFFFFFFU - len) {
    return BUFFER_E;  // overflow would happen, bail out
}

Or use the existing WC_SAFE_SUM_WORD32() macro if available.

Bottom line

Not a critical vuln but should be patched to keep the code robust. Better safe than sorry right?

Reproduction steps

How to trigger

Build with SE050 support:

./configure --enable-se050
# or in user_settings.h:
#define WOLFSSL_SE050_HASH

Need SE050 hardware connected via I2C.

Repro steps

Theoretical repro (not really exploitable irl due to hardware limits):

1. Init hash with se050_hash_init()
2. Keep calling se050_hash_update() until used nears 4GB
3. Pass len that causes used + len to overflow
4. BOOM - small alloc, big write = heap corruption

• Impact: Low-ish - SE050 max buffer is like 200KB, so hitting 4GB is basically impossible
• Risk: Still worth fixing for defense-in-depth
• Exploitable: Nah, not really, but it's bad practice to not check for overflow

Relevant log output

[zulfff]

Hey guys,

Honestly I thought this one wasn’t really a security issue, that’s why I opened it here hehe. If it actually turns out to be a real security vulnerability, I can move it over to Zendesk instead lol.

[kareem-wolfssl]

Hi @AryzXploit,

Thanks for the report. I've pushed #9954 to fix this. Please confirm if this fix looks good to you.

We do appreciate your reports, but in the future if you have any doubts about whether something is sensitive, please do use our Zendesk rather than Github. Thanks!

[zulfff]

Fix looks good! 👍

The WC_SAFE_SUM_WORD32 macro properly covers the overflow scenario. The check prevents the bad allocation before it happens, so no heap overflow.

As for future reports - noted on using Zendesk for sensitive stuff. I assessed this one as low severity since SE050 hardware limits make it hard to exploit, hence the public report.

Thanks for the quick patch!