[Webkit-unassigned] [Bug 41758] New: Integer signedness and under/overflows errors in RenderBlock

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41758

           Summary: Integer signedness and under/overflows errors in
                    RenderBlock
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows Vista
            Status: NEW
          Severity: Normal
          Priority: P1
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skylined at chromium.org
                CC: eric at webkit.org


We recently got some OOM crashes reported against Chrome concerning columns. The problem is caused by a runaway loop, which consumes memory. However, the problem appears to involve an integer underflow and a signedness error as well:
http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderBlock.cpp#L4266
// *** underflow (happened earlier): desiredColumnCount = -6
4175        int desiredColumnCount = info->m_desiredColumnCount;
<<<snip>>>
// *** signedness: colCount = 0xFFFFFFF9
4207        unsigned colCount = desiredColumnCount;
4208        int maxColBottom = borderTop() + paddingTop();
4209        int contentBottom = top + availableHeight;
4210        int minimumColumnHeight = -1;
// *** near infinite loop
4211        for (unsigned i = 0; i < colCount; i++) {
<<<snip>>>
4268            // Start adding in more columns as long as there's still content left.
4269            if (currY < endOfContent && i == colCount - 1 && (computeIntrinsicHeight || contentHeight()))
// *** potential for real infinite loop - is this guaranteed to terminate within reason?
4270                colCount++;
4271        }
Looking at the rest of the code, it appears that "int" and "unsigned" are used side by side without any regard to potential signedness errors. Also, calculations in the code do not appear to be checked for integer overflows or underflows. I am worried that there are worse issues in the code than OOM, but the repros in the original report do not appear to trigger any.

This code could definitely use a cleanup to make sure there is no potential for a security issue.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.