Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2b837edd2587d41faa63c8611720ca388405e6fa
      
https://github.com/WebKit/WebKit/commit/2b837edd2587d41faa63c8611720ca388405e6fa
  Author: Wenson Hsieh <wenson_hs...@apple.com>
  Date:   2022-12-20 (Tue, 20 Dec 2022)

  Changed paths:
    M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAlternateHTMLString.mm

  Log Message:
  -----------
  REGRESSION (257084@main): Mitigate crashes when calling into 
`WebPageProxy::loadAlternateHTML` with nil data
https://bugs.webkit.org/show_bug.cgi?id=249622
rdar://103459912

Reviewed by Aditya Keerthi.

Prior to the changes in 257084@main, attempting to call into 
`WebPageProxy::loadAlternateHTML` with
a nil `NSString` would trigger a load with what was (effectively) empty data, 
whether it's because
the WebKit client passed in `nil` for the HTML string, or if Foundation 
returned a nil `NSData` from
`-[NSString dataUsingEncoding:]`, whose return type is a `nullable NSData *`.

After 257084@main, this now results in a crash underneath `DataSegment::size()` 
when attempting to
call `CFDataGetLength` on `0x0`, after we send `AddAllowedFirstPartyForCookies` 
to the network
process and get a response.

While this could potentially be a client error, it's probably a good idea to 
apply a mitigation
within WebKit in this scenario, since:

-   This keeps behavior in line with shipping WebKit, and
-   `-[NSString dataUsingEncoding:]` is technically allowed to return a `nil` 
`NSData` from
    nullability annotations, though it's (admittedly) unclear how this would 
occur when passing in a
    UTF-8 string encoding.

Test: WKWebView.LoadNilAlternateHTMLStringDoesNotCrash

* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _loadAlternateHTMLString:baseURL:forUnreachableURL:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAlternateHTMLString.mm:
(TEST):

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


_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to