Skip to content

VPAAMP-872: Replace alloca with fixed stack arrays in logging functions - #1790

Merged
pstroffolino merged 2 commits into
dev_sprint_25_2from
feature/VPAAMP-872
Aug 4, 2026
Merged

VPAAMP-872: Replace alloca with fixed stack arrays in logging functions#1790
pstroffolino merged 2 commits into
dev_sprint_25_2from
feature/VPAAMP-872

Conversation

@pstroffolino

Copy link
Copy Markdown
Contributor

Security scanners flag alloca() usage within loops as a potential vulnerability. While the current usage is safe (fixed 2-iteration loop with bounded sizes), replacing with fixed stack arrays eliminates the security concern with zero performance impact.

Changes:

  • aamplogging.cpp: Replace alloca with 512-byte stack buffer for format string
  • PlayerLogManager.cpp: Replace alloca with 512-byte stack buffer for format string
  • Add bounds checking to prevent buffer overflow if format string exceeds 512 bytes

Performance: No measurable impact - stack allocation occurs at function entry regardless of alloca vs fixed array. 512 bytes is sufficient for all log prefixes (timestamp + player ID + log level + thread ID + function + line).

Security: Eliminates dynamic stack allocation pattern flagged by security scans.

Security scanners flag alloca() usage within loops as a potential vulnerability.
While the current usage is safe (fixed 2-iteration loop with bounded sizes),
replacing with fixed stack arrays eliminates the security concern with zero
performance impact.

Changes:
- aamplogging.cpp: Replace alloca with 512-byte stack buffer for format string
- PlayerLogManager.cpp: Replace alloca with 512-byte stack buffer for format string
- Add bounds checking to prevent buffer overflow if format string exceeds 512 bytes

Performance: No measurable impact - stack allocation occurs at function entry
regardless of alloca vs fixed array. 512 bytes is sufficient for all log
prefixes (timestamp + player ID + log level + thread ID + function + line).

Security: Eliminates dynamic stack allocation pattern flagged by security scans.
@pstroffolino
pstroffolino requested a review from a team as a code owner July 28, 2026 17:29
@pstroffolino
pstroffolino merged commit 57ea038 into dev_sprint_25_2 Aug 4, 2026
6 checks passed
@pstroffolino
pstroffolino deleted the feature/VPAAMP-872 branch August 4, 2026 18:34
@pstroffolino
pstroffolino requested a review from Copilot August 4, 2026 18:34

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR removes alloca() usage in the two logprintf() implementations by switching to a fixed-size stack buffer for the composed format string, aiming to satisfy security scanning guidance while keeping logging behavior and performance largely unchanged.

Changes:

  • Replaced alloca()-allocated format string buffers with a fixed char format_buffer[512] stack buffer.
  • Added size capping logic intended to prevent writes beyond the fixed buffer when constructing the composed format string.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
aamplogging.cpp Replace alloca() with a fixed stack buffer for composed log format string and add bounds capping.
middleware/playerLogManager/PlayerLogManager.cpp Same alloca() replacement and bounds capping for middleware logging.

Comment thread aamplogging.cpp
Comment on lines 149 to +153
format_bytes++; // include nul terminator
format_ptr = (char *)alloca(format_bytes); // allocate on stack
if (format_bytes > (int)sizeof(format_buffer))
{
format_bytes = sizeof(format_buffer);
}
Comment on lines 127 to +131
format_bytes++; // include nul terminator
format_ptr = (char *)alloca(format_bytes); // allocate on stack
if (format_bytes > (int)sizeof(format_buffer))
{
format_bytes = sizeof(format_buffer);
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants