Closed Bug 616412 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Security: CAPS, defect)

x86_64
Linux
defect
Not set

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: cjones, Assigned: cjones)

Details

(Keywords: valgrind)

Attachments

(1 file)

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.)
> (And so the *rv = NS_OK should be moved before the first if-stmt.)

I believe this is what we want.  Blake?
blocking2.0: --- → ?
Looks right to me. Chris, want to attach a patch?
Sure.
Assignee: nobody → jones.chris.g
Attachment #495648 - Flags: review?(mrbkap)
Comment on attachment 495648 [details] [diff] [review]
Fix use-before-init bug

Thanks!
Attachment #495648 - Flags: review?(mrbkap) → review+
Ping re: blocking/approval triage.
Comment on attachment 495648 [details] [diff] [review]
Fix use-before-init bug

a=me; this waiting is silly.
Attachment #495648 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/6e9e376c146b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Is there any way I can verify this fixed?
Not easily, the only observable and deterministic effect is to silence this valgrind warning.
Any objections to me just marking this verified?
Nope!  I did numerous valgrind runs after this patch, clean wrt this bug.
Status: RESOLVED → VERIFIED
blocking2.0: ? → betaN+
You need to log in before you can comment on or make changes to this bug.