Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: fe6390e70e71bf13a4c74dfd98cc6604cdc4f521
https://github.com/WebKit/WebKit/commit/fe6390e70e71bf13a4c74dfd98cc6604cdc4f521
Author: Sean Patterson <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
A
LayoutTests/fast/html/details-display-contents-scrollable-content-crash-expected.txt
A
LayoutTests/fast/html/details-display-contents-scrollable-content-crash.html
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
Log Message:
-----------
Cherry-pick 318661@main (9510cbdd8452).
https://bugs.webkit.org/show_bug.cgi?id=320447
Unreviewed backport.
Null-deref crash in RenderElement::resolvePseudoElementStyle() when a
<details> element has `display: contents` and its ::details-content establishes
a scrollable area
https://bugs.webkit.org/show_bug.cgi?id=320447
rdar://183445758
Reviewed by Simon Fraser.
rendererForScrollbar() maps a renderer inside a user agent shadow root to
its
shadow host's renderer, so that scrollbar pseudo element styles are resolved
against the host. It returned the host's renderer unconditionally, but a
host
with `display: contents` has no renderer. Its user agent shadow content can
still establish a scrollable area, so all three callers dereferenced null.
A <details> is exactly that case: its ::details-content is a slot in the
user
agent shadow root, so giving the <details> `display: contents` and the
::details-content non-visible overflow crashed the WebContent process while
resolving the scroll corner style during render tree construction. This is
the
standard way to build an animated disclosure widget whose summary
participates
in a parent grid, so it is reachable from ordinary content.
Null check the host's renderer and fall back to the renderer establishing
the
scrollable area, which is the pre-existing behavior for content outside a
user
agent shadow root. Only the null case changes behavior.
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::rendererForScrollbar): The host is not guaranteed to have a
renderer.
It has none when it is `display: contents`, even though its user agent
shadow
content may still establish a scrollable area. Fall back to the renderer
establishing the scrollable area rather than returning null, since the
callers
all dereference the result to resolve the scrollbar pseudo element styles
against it: updateScrollCornerStyle(), updateResizerStyle() and
createScrollbar().
*
LayoutTests/fast/html/details-display-contents-scrollable-content-crash.html:
Added.
*
LayoutTests/fast/html/details-display-contents-scrollable-content-crash-expected.txt:
Added.
Covers all three call sites: a scroll corner, a resizer (`resize: both`) and
scrollbar creation (`overflow: scroll` with overflowing content). Crashes
without the fix, passes with it.
Canonical link: https://commits.webkit.org/318661@main
Canonical link: https://commits.webkit.org/305877.1073@webkitglib/2.52
Commit: 9ddc4037a53c86ca8c8d2d60f93556eea1e4f4e5
https://github.com/WebKit/WebKit/commit/9ddc4037a53c86ca8c8d2d60f93556eea1e4f4e5
Author: Chris Dumez <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp
Log Message:
-----------
Cherry-pick 318204@main (5d91250a8529).
https://bugs.webkit.org/show_bug.cgi?id=320408
CacheStorage size accounting can underflow and persist a corrupt size
https://bugs.webkit.org/show_bug.cgi?id=320408
Reviewed by Youenn Fablet.
CacheStorageManager::sizeDecreased() subtracted the given amount from m_size
without checking that it did not exceed the current value. m_size is a
uint64_t,
so if the amount ever exceeds the tracked size the subtraction wraps to a
value
near UINT64_MAX, which is then written to the cache's size file and used for
quota accounting, effectively corrupting quota reporting for the origin
until
the size is re-initialized.
The tracked size is normally kept consistent (increments and decrements are
balanced in putRecordsInStore), but removeRecords() and removeAllRecords()
call
sizeDecreased() directly, outside the space-request/initialization path, so
the
in-memory accounting and the asynchronously-measured cache size can in
theory
drift and the decrement can exceed m_size.
Clamp the subtraction at zero, matching the saturating arithmetic used
elsewhere
in this code.
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp:
(WebKit::CacheStorageManager::sizeDecreased):
Canonical link: https://commits.webkit.org/318204@main
Canonical link: https://commits.webkit.org/305877.1074@webkitglib/2.52
Commit: 8856064cd3338034000f916fb5997c7e9c5b0898
https://github.com/WebKit/WebKit/commit/8856064cd3338034000f916fb5997c7e9c5b0898
Author: Chris Dumez <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/WebCore/platform/graphics/MIMESniffer.cpp
M Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp
Log Message:
-----------
Cherry-pick 318243@main (ef325e63cb21).
https://bugs.webkit.org/show_bug.cgi?id=320634
Out-of-bounds read in WebM MIME sniffer at the 0x42 0x82 DocType check
https://bugs.webkit.org/show_bug.cgi?id=320634
Reviewed by Youenn Fablet.
314498@main guarded the inner skip-NUL loop in hasSignatureForWebM(),
but a second unguarded iter + 1 read remains at the top of the loop:
```
while (iter < length && iter < 38) {
if (sequence[iter] == 0x42 && sequence[iter + 1] == 0x82) {
```
The loop guard only guarantees iter < length, not iter + 1 < length. When
iter == length - 1 and sequence[iter] == 0x42, the short-circuit && goes on
to evaluate sequence[iter + 1], reading one byte past the end of the span.
This is reachable before the skip-NUL path 314498@main fixed: a 5-byte
input of EBML magic + a trailing 0x42 (0x1A 0x45 0xDF 0xA3 0x42) enters the
loop at iter == 4 == length - 1 and reads sequence[5].
getMIMETypeFromContent()
is called on attacker-controlled response bytes via MediaResourceSniffer
with
a span sized to the exact number of received bytes, so this is a remotely
reachable crash. WebKit builds with hardened libc++, so std::span's bounds
check turns it into a safe abort on every build.
Guard the two-byte compare with iter + 1 < length so the bounds check
short-circuits the dereference, matching the guarded reads later in the
function, and extend the regression test with the truncated 5-byte input.
Test: MIMESniffer.WebMSnifferDoesNotReadPastEnd
* Source/WebCore/platform/graphics/MIMESniffer.cpp:
(WebCore::MIMESniffer::hasSignatureForWebM):
* Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp:
(TestWebKitAPI::TEST(MIMESniffer, WebMSnifferDoesNotReadPastEnd)):
Canonical link: https://commits.webkit.org/318243@main
Canonical link: https://commits.webkit.org/305877.1075@webkitglib/2.52
Commit: 4c2258af828b4833870638c838e4cba0457ee338
https://github.com/WebKit/WebKit/commit/4c2258af828b4833870638c838e4cba0457ee338
Author: Sam Sneddon <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/WebKit/UIProcess/Automation/SimulatedInputDispatcher.cpp
Log Message:
-----------
Cherry-pick 317834@main (e59b5d3cc487).
https://bugs.webkit.org/show_bug.cgi?id=319610
REGRESSION(283790@main): the touch path didn't adopt mouseInteraction and
no longer works
https://bugs.webkit.org/show_bug.cgi?id=319610
rdar://182438327
Reviewed by BJ Burg.
The Touch branch of transitionInputSourceToState never adopted
283790@main's change to dispatch off b.mouseInteraction: it still
infers TouchDown/LiftUp/MoveTo purely from pressedMouseButton edges.
safaridriver's paired fix for the same bug stopped clearing
pressedMouseButton on pointerUp, relying on mouseInteraction alone to
signal Up, so pressedMouseButton now stays set across the whole
pointerDown/pointerUp pair. Since the Touch branch only emits LiftUp
when pressedMouseButton goes from set to unset, no LiftUp is emitted
for the pointerUp action itself; the touch stays held until the next
command (or the Release Actions reset keyframe) lifts it late and at
the wrong coordinate.
Port 283790@main's approach to the Touch branch, mirroring the
Mouse/Pen branch exactly: dispatch off b.mouseInteraction with no
pressedMouseButton-delta fallback. This makes the Up keyframe's
resolveLocation(origin=Pointer, location=(0,0)) resolve to the down
coordinate, so LiftUp now fires in place during the pointerUp action's
own keyframe transition.
* Source/WebKit/UIProcess/Automation/SimulatedInputDispatcher.cpp:
(WebKit::touchInteractionForMouseInteraction):
(WebKit::SimulatedInputDispatcher::transitionInputSourceToState):
Canonical link: https://commits.webkit.org/317834@main
Canonical link: https://commits.webkit.org/305877.1076@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/97b45927eca5...4c2258af828b
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
