Fix 3 RCEs in packet parsing and texture loading

[JuelzIrons]

Description

This PR fixes 2 RCE vulnerabilities in Packet Parsing and 1 in texture loading

Changes

Previous Behavior

packets with crafted RoomSyncData or AddPlayerFailed sizes had no validation, allowing integer overflow and unbounded heap allocation and wsprintfW in AbstractTexturePack.cpp had no size limit on the output buffer.

Root Cause

Old code had no bounds checking on network packet sizes, and wsprintfW had no buffer size parameter.

New Behavior

Packet sizes are validated and capped before allocation. swprintf_s enforces buffer size on string formatting.

Fix Implementation

wsprintfW replaced with swprintf_s with LOCATOR_SIZE in AbstractTexturePack.cpp
RoomSyncData and AddPlayerFailed packet parsing now reads size into receivedSize, rejects if < 0 || > 100000, checks totalSize for integer overflow before allocating

AI Use Disclosure

No AI was used in the discovery or patching of these RCEs

Related Issues

N/A

[JuelzIrons]

I decreased the limit to 512kb + added comments as to why its 512kb
1mb was more or so a miscalculation on my end,

512 is still on the forgiving side still but it still prevents the overflow

[irice7]

Curious, is this actually an exploitable RCE?

[codeHusky]

Is this limit theoretically sufficient for, say, 90 players of information? We shouldn’t be setting limits for low player counts realistically

[JuelzIrons]

Is this limit theoretically sufficient for, say, 90 players of information? We shouldn’t be setting limits for low player counts realistically

No not at all. I was just thinking of the default 8 that the game supports not keeping the servers having more in mind
Ill have to fix it tomorrow as its late in my timezone

[JuelzIrons]

yea imma just not do this, they arent even exploitable in any reliable manner anyways