Fixed a potential integer overflow issue in the read_ulong_be function by adding an explicit cast to ULONG before bit shifting. The data[0] byte was being shifted left 24 bits without proper casting, which could cause overflow when the byte value is large and the compiler treats it as a signed char. This ensures proper 32-bit unsigned integer behavior during the bitwise OR operations.
From: Wei Xie xiewei@uniontech.com
Fixed a potential integer overflow issue in the read_ulong_be function by adding an explicit cast to ULONG before bit shifting. The data[0] byte was being shifted left 24 bits without proper casting, which could cause overflow when the byte value is large and the compiler treats it as a signed char. This ensures proper 32-bit unsigned integer behavior during the bitwise OR operations. --- dlls/windowscodecs/pngformat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/windowscodecs/pngformat.c b/dlls/windowscodecs/pngformat.c index 77bfbdc4866..4e4677820eb 100644 --- a/dlls/windowscodecs/pngformat.c +++ b/dlls/windowscodecs/pngformat.c @@ -37,7 +37,7 @@ static inline USHORT read_ushort_be(BYTE* data)
static inline ULONG read_ulong_be(BYTE* data) { - return data[0] << 24 | data[1] << 16 | data[2] << 8 | data[3]; + return ((ULONG)data[0] << 24) | data[1] << 16 | data[2] << 8 | data[3]; }
static HRESULT LoadTextMetadata(MetadataHandler *handler, IStream *stream, const GUID *preferred_vendor,
[But BYTE is explicitly unsigned?](https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types)
On Mon Nov 3 07:40:22 2025 +0000, Alfred Agrell wrote:
[But BYTE is explicitly unsigned?](https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types)
Wait, you're right, bitshifting an unsigned char promotes to signed int. Signed char is irrelevant, but the patch is correct.
This merge request was approved by Esme Povirk.
-
Alfred Agrell (＠Alcaro) -
Esme Povirk (＠madewokherd)
-
Wei Xie
-
Wei Xie (＠wayne)