Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: c3727f4d350a8989ee689b64acbb25337dd33d15
https://github.com/WebKit/WebKit/commit/c3727f4d350a8989ee689b64acbb25337dd33d15
Author: Justin Michaud <[email protected]>
Date: 2026-08-21 (Fri, 21 Aug 2026)
Changed paths:
M Source/JavaScriptCore/runtime/Options.cpp
M Source/JavaScriptCore/runtime/Options.h
Log Message:
-----------
Cherry-pick 319464@main (1c2c282d06f0).
https://bugs.webkit.org/show_bug.cgi?id=321653
Set a more reasonable default number of wasm threads
https://bugs.webkit.org/show_bug.cgi?id=321653
Reviewed by Carlos Alberto Lopez Perez.
We have some wasm OOM crashes on the bots because they have
very high core counts but not enough memory.
Ex: https://build.webkit.org/#/builders/2018/builds/44
Let's pick a more reasonable number of default wasm threads.
Canonical link: https://commits.webkit.org/319464@main
Canonical link: https://commits.webkit.org/317695.124@webkitglib/2.54
Commit: f84f08b5294e6ee90848b4e12bc383e095c36c22
https://github.com/WebKit/WebKit/commit/f84f08b5294e6ee90848b4e12bc383e095c36c22
Author: Sabith Saheb <[email protected]>
Date: 2026-08-21 (Fri, 21 Aug 2026)
Changed paths:
A LayoutTests/fast/images/bmp-rle24-absolute-run-crash-expected.txt
A LayoutTests/fast/images/bmp-rle24-absolute-run-crash.html
A LayoutTests/fast/images/resources/bmp-rle24-absolute-run-crash.bmp
M Source/WebCore/platform/image-decoders/bmp/BMPImageReader.cpp
M Source/WebCore/platform/image-decoders/bmp/BMPImageReader.h
Log Message:
-----------
Cherry-pick 319523@main (e269e1967d8d).
https://bugs.webkit.org/show_bug.cgi?id=321680
Out-of-bounds read in BMP RLE24 absolute-mode decoding
https://bugs.webkit.org/show_bug.cgi?id=321680
Reviewed by Michael Catanzaro.
processNonRLEData() reuses readCurrentPixel() to decode RLE24 absolute-mode
runs, but readCurrentPixel() derives its byte offset from the absolute
column
(m_coord.x() * bytesPerPixel), assuming m_decodedOffset points at the start
of
the row. That holds for non-RLE rows, which always begin at column 0, but an
RLE absolute run can begin mid-row after an encoded run advanced the column
through fillRGBA(). There m_decodedOffset points at the run's pixel bytes,
so
each read lands startX * 3 bytes too far. The InsufficientData check only
reserves paddedNumBytes for the run length, so a truncated RLE24 bitmap
whose
absolute run starts at a non-zero column reads past the end of the
SharedBuffer.
Read run-relative instead, matching the paletted RLE8/RLE4 branch which
already
indexes from the start of the run. Since readCurrentPixel() has a single
caller
and its offset now depends on where the block being decoded started, move it
out of the header and into processNonRLEData() as a local lambda. The
non-RLE
path is unaffected because its rows start at column 0.
Added a regression test that decodes a truncated OS/2 RLE24 BMP whose
absolute-mode run begins at a non-zero column. Because the reads are backed
by
std::span, the old code took a guaranteed out-of-bounds read (and crash) on
this input; with the fix the reads stay inside the run and decoding fails
cleanly instead.
* Source/WebCore/platform/image-decoders/bmp/BMPImageReader.cpp:
(WebCore::BMPImageReader::processNonRLEData):
* Source/WebCore/platform/image-decoders/bmp/BMPImageReader.h:
(WebCore::BMPImageReader::readCurrentPixel): Deleted.
* LayoutTests/fast/images/bmp-rle24-absolute-run-crash.html: Added.
* LayoutTests/fast/images/bmp-rle24-absolute-run-crash-expected.txt: Added.
* LayoutTests/fast/images/resources/bmp-rle24-absolute-run-crash.bmp: Added.
Canonical link: https://commits.webkit.org/319523@main
Canonical link: https://commits.webkit.org/317695.125@webkitglib/2.54
Commit: 9746f856e68cfcf3241ff2221bd9263ad06d3079
https://github.com/WebKit/WebKit/commit/9746f856e68cfcf3241ff2221bd9263ad06d3079
Author: Sabith Saheb <[email protected]>
Date: 2026-08-21 (Fri, 21 Aug 2026)
Changed paths:
A LayoutTests/fast/images/animated-png-icc-transform-crash-expected.txt
A LayoutTests/fast/images/animated-png-icc-transform-crash.html
A LayoutTests/fast/images/resources/animated-png-icc-transform-crash.png
M Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp
Log Message:
-----------
Cherry-pick 319524@main (5b391e6d3b14).
https://bugs.webkit.org/show_bug.cgi?id=321680
Out-of-bounds write in PNGImageDecoder::frameComplete() ICC transform
Reviewed by Michael Catanzaro.
1. destinationRow starts at pixelsStartingAt(rect.x(), y) and the loop above
writes rect.width() pixels, but cmsDoTransform gets rect.maxX() as its
pixel
count.
2. With a TYPE_BGRA_8 transform that is a 4-byte-per-pixel
read-modify-write, so
once 2*rect.x() + rect.width() passes the canvas width it runs off each
row,
and on the last row (yOffset + height == height) past the pixel
allocation.
The only fcTL guard is xOffset + width <= width, which does not stop
that;
reachable from an animated PNG with an RGB iCCP chunk on ports built with
USE(LCMS) (GTK, WPE).
Pass rect.width() so the count matches the row-relative span, like the
first-frame path in rowAvailable().
* Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:
(WebCore::PNGImageDecoder::frameComplete):
Test: fast/images/animated-png-icc-transform-crash.html
* LayoutTests/fast/images/animated-png-icc-transform-crash.html: Added.
* LayoutTests/fast/images/animated-png-icc-transform-crash-expected.txt:
Added.
* LayoutTests/fast/images/resources/animated-png-icc-transform-crash.png:
Added.
Canonical link: https://commits.webkit.org/319524@main
Canonical link: https://commits.webkit.org/317695.126@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/09cafca4f96b...9746f856e68c
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
