Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 879979bad0672e1858748d40855497d2c811bc3b
https://github.com/WebKit/WebKit/commit/879979bad0672e1858748d40855497d2c811bc3b
Author: Sabith Saheb <[email protected]>
Date: 2026-08-20 (Thu, 20 Aug 2026)
Changed paths:
M Source/WebCore/platform/graphics/opentype/OpenTypeVerticalData.cpp
Log Message:
-----------
Cherry-pick 319036@main (2196077a54c4). <bug>
Out-of-bounds read in OpenType vertical GSUB coverage range fill
https://bugs.webkit.org/show_bug.cgi?id=
Reviewed by Michael Catanzaro.
OpenTypeVerticalData loads vertical glyph substitutions from a
downloaded font's GSUB table, which is attacker controlled.
LookupTable::getSubstitutions() fills the substitution map one Coverage
Format 2 range at a time. from and fromEnd were uint16_t with fromEnd
set to end + 1, so a range whose end is 0xffff wraps fromEnd to 0. The
guard indexTo + (fromEnd - from) > countTo then underflows on the
truncated value and passes, and the inner loop walks from start through
0xffff before from wraps back to 0, reading
singleSubstitution2->substitute[indexTo] far past its validated
glyphCount entries. substitute is a raw pointer into the GSUB buffer, so
this is an unchecked heap read past the table. A reversed range with
start greater than end underflows the same guard.
Widen from and fromEnd to unsigned so end + 1 stays exact, and reject
fromEnd <= from to drop reversed and empty ranges before the copy. Valid
ranges map the same glyphs as before.
* Source/WebCore/platform/graphics/opentype/OpenTypeVerticalData.cpp:
(WebCore::OpenType::LookupTable::getSubstitutions):
Canonical link: https://commits.webkit.org/319036@main
Canonical link: https://commits.webkit.org/305877.1110@webkitglib/2.52
Commit: 6fd2892a2a580866323901433f6c97b09017af47
https://github.com/WebKit/WebKit/commit/6fd2892a2a580866323901433f6c97b09017af47
Author: Fady Farag <[email protected]>
Date: 2026-08-20 (Thu, 20 Aug 2026)
Changed paths:
M Source/WebCore/bindings/js/WebAssemblyScriptBufferSourceProvider.h
Log Message:
-----------
Cherry-pick 319496@main (a1306c500f0b).
https://bugs.webkit.org/show_bug.cgi?id=322153
Use-after-move in `WebAssemblyScriptBufferSourceProvider::create()`
https://bugs.webkit.org/show_bug.cgi?id=322153
rdar://185374718
Reviewed by Yusuke Suzuki.
ISO C++ does not guarantee the evaluation order of function arguments.
The constructor call here both moved `sourceURL` and read it via
`sourceURL.string()`, so the use and the move were unsequenced.
* Source/WebCore/bindings/js/WebAssemblyScriptBufferSourceProvider.h:
Canonical link: https://commits.webkit.org/319496@main
Canonical link: https://commits.webkit.org/305877.1111@webkitglib/2.52
Commit: ebcd65a67f0a5fc951cfa4bd577825d7c2441d88
https://github.com/WebKit/WebKit/commit/ebcd65a67f0a5fc951cfa4bd577825d7c2441d88
Author: Sabith Saheb <[email protected]>
Date: 2026-08-20 (Thu, 20 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=322153
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/305877.1112@webkitglib/2.52
Commit: 3cf0167134fd56f43be915d20b490bfcb6415873
https://github.com/WebKit/WebKit/commit/3cf0167134fd56f43be915d20b490bfcb6415873
Author: Sabith Saheb <[email protected]>
Date: 2026-08-20 (Thu, 20 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/305877.1113@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/6733d583efbd...3cf0167134fd
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
