Vulnerability fixes (2/3) - #22012
Merged
Merged
Conversation
MakeCacheSpaceFor freed cache blocks (allocated with new u8[]) using scalar delete instead of delete[]. Correct to delete[].
pngLoadPtr allocated the decoded buffer directly from attacker-controlled PNG IHDR dimensions with no upper bound, so browsing a crafted game icon or savedata could trigger a multi-gigabyte allocation. - Add maxWidth/maxHeight parameters to pngLoadPtr (default 8192x8192) and reject images larger than the limits. - Thread the limits through LoadTextureLevelsFromFileData, CreateTextureFromFileData, and CreateTextureFromFile. - Limit game icons to 256x128 in GameInfoCache and IconCache.
DISC_ID/DISC_VERSION/homebrewName are attacker-controlled and were used unsanitized to build migration rename paths. Skip the migration step if any of them contain a '/' or '\' so the destination can't escape the savestate directory.
The loop-with-trailer streaming path copied 'secondBufferByte % sampleSize' bytes into the main buffer with no clamp. sampleSize is file-derived, so a crafted value could overflow the destination. Clamp the copy length to info.bufferByte.
PointerWrap tracked no end-of-buffer, so DoState() implementations could read past the end of a crafted or truncated savestate via DoVoid's unchecked memcpy, and DoVector could resize to an attacker-controlled size before reading. - PointerWrap now tracks a read end; DoVoid/ExpectVoid fail (MODE_NOOP) before reading out of bounds. - String reads are bounds-checked for the whole string including NUL. - DoVector rejects sizes that can't fit in the remaining buffer. - LoadPtr takes the buffer size and sets the read end. - Capping the decompression buffer allocation in LoadFile.
The null check for getAtrac() only logged a warning and fell through to a virtual call on the null pointer. Return 0 on invalid atrac ID.
… errors - InitContextFromTrackInfo now rejects files where sampleSize (from blockAlign) exceeds the buffer size, instead of only clamping later in DecodeForSas. Keep the DecodeForSas check as defense-in-depth since a large buffer could still allow a crafted packet to overflow the fixed assembly buffer. - CChunkFileReader::Verify now returns ERROR_BROKEN_STATE if bounds checking fails, so modified savestates are rejected here too.
The import debug reporter used IsValidAddress (start-address only) before formatting module names with %s, so a crafted unterminated name could be read past guest RAM. Use IsValidNullTerminatedString instead.
pmf_init reported stream dimensions without a cap, and PMFView::Draw allocated width * height * 4 with 32-bit int arithmetic, so a crafted ICON1.PMF could overflow the allocation to a small buffer while sws_scale wrote the full frame. - Reject videos with dimensions outside 1..720x480 in pmf_init (PMFs on the PSP never exceed 720x480). - Use size_t arithmetic for the frame buffer allocation.
A malicious or MITM'd server could send a Content-Range header matching the requested range but a larger entity body, overflowing the caller's fixed-size buffer via output.Take. Clamp the copied size to the requested range.
PGF::ReadPtr walked four length-prefixed tables and computed table sizes before any bounds check, and used signed 32-bit size math that could overflow, allowing a crafted font to read past the input buffer. - Validate the total size of all tables up front using 64-bit math. - Check the rev3 extra header fits before reading it. - Cap charPointerLength/charMapLength/shadowMapLength to avoid absurd allocations. - Bounds-check glyph data offsets before reading each glyph. Also throw in a warning fix
ReadCharGlyph read glyph metadata at an attacker-controlled bit offset with no validation, and ReadShadowGlyph only checked after delegating to it. Validate charPtr (with margin for the header reads) at the top of ReadCharGlyph so it is safe regardless of caller, and drop the now redundant checks at the ReadPtr call sites.
EP_MAP_STRIDE * EPMapEntriesNum was computed in 32-bit and could wrap, passing the range check while the loop read the unwrapped count; and the check was skipped entirely when headerOffset == 0 (the player tempbuf path). - Use 64-bit math for the EP map size. - Keep the guest-RAM range check when headerOffset != 0. - Cap the entry count for the headerOffset == 0 path so the reads stay within the player's 64KB tempbuf.
AnalyzeAtracTrack used max(fileSize, size) as the chunk-parse bound with fileSize taken from the file's RIFF header, so a crafted inflated RIFF size could push reads past the end of the buffer. Keep the real-library behavior of tolerating a too-low size, but clamp the parse bound to the actual mapped guest memory at the buffer. Also guard ParseWaveAT3's RIFF scan against a blockSize < 4 underflow that could make the offset negative and bypass the loop bounds check, and clamp readSize to the mapped region in Atrac2::SetData before parsing.
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 5 to 5.6.0. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v5...v5.6.0) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: 5.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [softprops/action-gh-release](https://github.com/softprops/action-gh-release) from 3.0.1 to 3.0.2. - [Release notes](https://github.com/softprops/action-gh-release/releases) - [Changelog](https://github.com/softprops/action-gh-release/blob/master/CHANGELOG.md) - [Commits](softprops/action-gh-release@718ea10...3d0d988) --- updated-dependencies: - dependency-name: softprops/action-gh-release dependency-version: 3.0.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
This was referenced Aug 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Again I've used AI (DeepSeek) to fix AI-discovered vulnerabilities, but it's mostly doing a really good job. I had to steer it carefully in a couple of cases though to not break things.
Also incorporates: