fix: finding triggers whenever there is a strcpy or ... in...

[orbisai0security]

Summary

Fix high severity security issue in deps/jemalloc/src/malloc_io.c.

Vulnerability

Field	Value
ID	c.lang.security.insecure-use-string-copy-fn.insecure-use-string-copy-fn
Severity	HIGH
Scanner	semgrep
Rule	c.lang.security.insecure-use-string-copy-fn.insecure-use-string-copy-fn
File	deps/jemalloc/src/malloc_io.c:102

Description: Finding triggers whenever there is a strcpy or strncpy used. This is an issue because strcpy does not affirm the size of the destination array and strncpy will not automatically NULL-terminate strings. This can lead to buffer overflows, which can cause program crashes and potentially let an attacker inject code in the program. Fix this by using strcpy_s instead (although note that strcpy_s is an optional part of the C11 standard, and so may not be available).

Changes

• deps/jemalloc/src/malloc_io.c

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[xdk-amz]

Fix DCO + add a test in jemalloc

[xdk-amz]

also suggest sending this to jemalloc instead and then pull it in here

[madolson]

This isn't a real bug though is it?

[orbisai0security]

Thanks, after re-checking the code path, I agree this is not a demonstrated security bug as written.

The original code uses strncpy(buf, b, buflen) followed immediately by buf[buflen - 1] = '\0', so the usual strncpy non-termination concern is already addressed here. My PR was based on a generic scanner finding and is better characterised as defensive cleanup rather than a confirmed vulnerability.

Given this is vendored jemalloc code, I’m happy to take it upstream to jemalloc first if maintainers still prefer the snprintf style.

I’ll also fix the DCO.

[orbisai0security]

I've raised a PR in jemalloc.