616412 - "Conditional jump or move depends on uninitialised value(s)" in nsScriptSecurityManager::CheckFunctionAccess

Status: VERIFIED FIXED

(Core :: Security: CAPS, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The problematic code appears to be

nsScriptSecurityManager::CheckFunctionAccess(JSContext *aCx, void *aFunObj,
                                             void *aTargetObj)
{
    // This check is called for event handlers
    nsresult rv;
    nsIPrincipal* subject =
        GetFunctionObjectPrincipal(aCx, (JSObject *)aFunObj, nsnull, &rv);

    // If subject is null, get a principal from the function object's scope.
    if (NS_SUCCEEDED(rv) && !subject)

nsIPrincipal*
nsScriptSecurityManager::GetFunctionObjectPrincipal(JSContext *cx,
                                                    JSObject *obj,
                                                    JSStackFrame *fp,
                                                    nsresult *rv)
{
    NS_PRECONDITION(rv, "Null out param");
    if (!JS_ObjectIsFunction(cx, obj))
    {
        // Protect against pseudo-functions (like SJOWs).
        nsIPrincipal *result = doGetObjectPrincipal(obj);
        if (!result)
            *rv = NS_ERROR_FAILURE;
        return result;
    }

If we hit the |!JS_ObjectIsFunction(cx, obj)| case, and then we get a non-null |result|, |rv| won't be written.  Maybe the condition in the first if-stmt in CheckFunctionAccess should be reversed?  Or is it OK to to have a non-null |result| in the |!JS_ObjectIsFunction(cx, obj)| case?  (And so the *rv = NS_OK should be moved before the first if-stmt.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

> (And so the *rv = NS_OK should be moved before the first if-stmt.)

I believe this is what we want.  Blake?

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Looks right to me. Chris, want to attach a patch?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Fix use-before-init bug

Sure.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 495648 [details] [diff] [review]
Fix use-before-init bug

Thanks!

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Ping re: blocking/approval triage.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 495648 [details] [diff] [review]
Fix use-before-init bug

a=me; this waiting is silly.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://hg.mozilla.org/mozilla-central/rev/6e9e376c146b

Comment 8

[u279076]

Is there any way I can verify this fixed?

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Not easily, the only observable and deterministic effect is to silence this valgrind warning.

Comment 10

[u279076]

Any objections to me just marking this verified?

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Nope!  I did numerous valgrind runs after this patch, clean wrt this bug.