Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 04e3d47960f3135b16aff2382ac0d1b712e0d884
      
https://github.com/WebKit/WebKit/commit/04e3d47960f3135b16aff2382ac0d1b712e0d884
  Author: Chris Dumez <[email protected]>
  Date:   2026-07-28 (Tue, 28 Jul 2026)

  Changed paths:
    M Source/WTF/wtf/URL.h
    M Source/WebKit/Shared/WTFArgumentCoders.serialization.in
    M Tools/TestWebKitAPI/Tests/IPC/ArgumentCoderTests.cpp

  Log Message:
  -----------
  Limit URL size at the IPC boundary to match Chrome/Blink
https://bugs.webkit.org/show_bug.cgi?id=320340
rdar://183139377

Reviewed by Abrar Rahman Protyasha.

Spindumps of watchdog-terminated MobileSafari showed the UIProcess main
thread spinning while decoding a DecidePolicyForNavigationAction message:
the ResourceRequest it carries holds a pathologically large URL, and
decoding it re-parses that URL on the main thread, which can burn seconds
of CPU and trip the process watchdog.

Reject over-sized URLs when decoding them for IPC, matching Chromium. Chromium
caps every URL crossing a process boundary at url::kMaxURLChars (2MB) in its
GURL and KURL mojo traits, whose Read() returns false past that length; the
URL is never parsed. Do the same via a Validator on the WTF::URL IPC decoder:
the validator runs on the raw string before the URL is constructed, so an
over-sized URL is rejected (the message is treated as invalid) without being
parsed. The limit is WTF::maxURLLength, matching kMaxURLChars.

For now the validator is enabled on Cocoa only. A failed decode is treated as
an invalid message and terminates the sender, so the limit is only safe where
a legitimately-large URL never crosses this boundary. On Cocoa, data: URLs are
loaded in-process (WebLoaderStrategy::startLocalLoad), so they do not cross it.
On the other ports (GTK/WPE/Win/PlayStation) data: URLs are loaded by the
NetworkProcess (NetworkDataTaskDataURL, routed via NetworkDataTask::create), so
a large-but-legitimate data: URL does cross this boundary and rejecting it would
terminate the process (e.g. large canvas.toDataURL() images). Enabling
the limit on the other ports requires either loading data: URLs in-process there
too, or capping navigation URLs specifically rather than every URL on the wire.

Test: TestWebKitAPI ArgumentCoderURL.*

* Source/WTF/wtf/URL.h:
Add WTF::maxURLLength (2MB, matching url::kMaxURLChars).
* Source/WebKit/Shared/WTFArgumentCoders.serialization.in:
Reject URLs longer than WTF::maxURLLength when decoding WTF::URL, on Cocoa.
* Tools/TestWebKitAPI/Tests/IPC/ArgumentCoderTests.cpp:
(TestWebKitAPI::makeURLStringOfLength): Added.
(TestWebKitAPI::decodeURLFromWireString): Added.
Add ArgumentCoderURL tests for round-trip, the at-limit boundary, and (on
Cocoa) decode rejection over the limit.

Canonical link: https://commits.webkit.org/318045@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to