Bug 209987 - Use-after-move of `formState` in WebCore::PolicyChecker::checkNavigationPolicy()
Summary: Use-after-move of `formState` in WebCore::PolicyChecker::checkNavigationPolicy()
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
Keywords: InRadar
Depends on:
Reported: 2020-04-03 14:23 PDT by David Kilzer (:ddkilzer)
Modified: 2020-04-03 17:16 PDT (History)
11 users (show)

See Also:

Patch (2.08 KB, patch)
2020-04-03 16:48 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2020-04-03 14:23:09 PDT
Use-after-move of `formState` in WebCore::PolicyChecker::checkNavigationPolicy().

The last if/else statement uses formState.get(), but that's been moved into the `decisionHandler` lambda.

void PolicyChecker::checkNavigationPolicy(ResourceRequest&& request, const ResourceResponse& redirectResponse, DocumentLoader* loader, RefPtr<FormState>&& formState, NavigationPolicyDecisionFunction&& function, PolicyDecisionMode policyDecisionMode)
    FramePolicyFunction decisionHandler = [this, function = WTFMove(function), request = ResourceRequest(request), formState = WTFMove(formState), suggestedFilename = WTFMove(suggestedFilename),
         blobURLLifetimeExtension = WTFMove(blobURLLifetimeExtension), requestIdentifier, isInitialEmptyDocumentLoad] (PolicyAction policyAction, PolicyCheckIdentifier responseIdentifier) mutable {

    if (isInitialEmptyDocumentLoad) {
        // We ignore the response from the client for initial empty document loads and proceed with the load synchronously.
        m_frame.loader().client().dispatchDecidePolicyForNavigationAction(action, request, redirectResponse, formState.get(), policyDecisionMode, requestIdentifier, [](PolicyAction, PolicyCheckIdentifier) { });
        decisionHandler(PolicyAction::Use, requestIdentifier);
    } else
        m_frame.loader().client().dispatchDecidePolicyForNavigationAction(action, request, redirectResponse, formState.get(), policyDecisionMode, requestIdentifier, WTFMove(decisionHandler));
Comment 1 David Kilzer (:ddkilzer) 2020-04-03 14:32:00 PDT
Not sure the best way to fix this.  Should WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction() be changed to take a RefPtr<FormState>&& instead of a FormState* and the `decisionHandler` just make a copy of `formState` instead of moving it?
Comment 2 Radar WebKit Bug Importer 2020-04-03 15:36:46 PDT
Comment 3 Chris Dumez 2020-04-03 15:46:13 PDT
I think Alex found it a few days ago too.
Comment 4 Chris Dumez 2020-04-03 15:48:22 PDT
(In reply to Chris Dumez from comment #3)
> I think Alex found it a few days ago too.

I believe he has a pending fix for it.

Also, I don't see why this is a security bug. The behavior of the RefPtr<> move constructor is well defined. We simply pass null the second time if it was already moved (which was intentional behavior).

Anyway, AFAICT, the current code is safe and correct. I do agree that it is bad practice though and should be written some other way (which I believe Alex is doing).
Comment 5 Ryosuke Niwa 2020-04-03 15:55:29 PDT
Okay, back to normal component.
Comment 6 Chris Dumez 2020-04-03 15:58:51 PDT
Should be coordinated with Alex because I think he is in the process of refactoring this code (and fixing this at the same time) I believe.

That said, a trivial fix would be to replace WTFMove(formState), std::exchange(formState, nullptr). It is equivalent given our current implementation of the RefPtr<> move constructor but looks safer.
Comment 7 Alex Christensen 2020-04-03 16:46:57 PDT
I fixed a similar use-after-move in WebPageProxy::receivedNavigationPolicyDecision in r259307.  We should use std::exchange here and be well defined without changing behavior.
Comment 8 Alex Christensen 2020-04-03 16:48:49 PDT
Created attachment 395418 [details]
Comment 9 EWS 2020-04-03 17:16:09 PDT
Committed r259522: <https://trac.webkit.org/changeset/259522>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 395418 [details].