fix: ServiceTag %ls buffer overread in Profile UI (stack corruption)

[kirklandsig]

Hey Jack — kirklandsig here. While hunting a long-standing crash in my fork (users crashing on Apply Profile → Save Profile), I traced it to this line, and your master carries the same code, so sending the fix upstream.

The bug

ServiceTag is a fixed wchar_t[4] with no null terminator — a legitimate 4-character tag ("ODST", "117X", …) fills every slot. CUserProfile::ImGuiContext does:

sprintf(buffer, "%ls", ServiceTag);

%ls walks memory until it hits a null word, so with a full 4-char tag it reads past the array into adjacent struct memory, and — if the following bytes happen to be non-zero for long enough — overflows the 1024-byte stack buffer. This executes every frame the Profile section is rendered.

It's sneaky because dev-created profiles start zero-filled (safe); the dangerous data arrives when a real player profile with a full tag is copied in. In my fork that's the "Apply Profile" flow, which matched the crash reports exactly: unreproducible locally, deterministic for users with 4-char service tags.

The fix

• Convert through a null-terminated wchar_t[5] copy before printing (bounded, no behavior change for shorter tags).
• wmemset the field before writing an edit back, so shortening a tag can't leave stale trailing characters that recreate the unterminated state.

Kept dependency-free/inline so it drops straight into your tree. In my fork this shipped in v1.4.5-experimental (over there it's factored into shared String helpers; happy to PR that variant instead if you prefer). Compile-verified in my fork where ImGuiContext is byte-identical around this block — I haven't built your vcpkg/SDL2 setup, so a quick build check on your side would be appreciated.

Thanks for porting my earlier changes into your beta, by the way — figured I'd return the favor.

🤖 Generated with Claude Code