Closed Bug 530696 Opened 16 years ago Closed 15 years ago

Potential crash or buffer overrun [@ SimpleBuffer::EnsureCapacity]

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: dveditz, Unassigned)

Details

(Keywords: crash, Whiteboard: [sg:dos] null deref, but critical if fixed naively)

Crash Data

SimpleBuffer::EnsureCapacity has no way to signal that it failed to grow capacity if too much was asked for causing malloc to fail. This situation does tend to come up in graphics programming. On the other hand newdata is used without checking for null, so we'd immediately crash in this situation. Safe, at least, but if that crash were fixed with a simple null check we'd end up with buffer overruns. Do we want it to crash on a too-large request? Most EnsureCapacity-like places in the code return a boolean and the return value is checked before using the buffer.
Keywords: crash
Whiteboard: [sg:dos] null deref, but critical if fixed naively
Version: 1.9.2 Branch → Trunk
No, I don't think we want it to crash, at least in the cases where we have a known allocation point which can be easily controlled by content.
Summary: Potential crash or buffer overrun in SimpleBuffer::EnsureCapacity → Potential crash or buffer overrun [@ SimpleBuffer::EnsureCapacity]
SimpleBuffer usage is gone; closing this off. The situation described should be handled in the JS layer, where these buffers are created now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Group: core-security
Crash Signature: [@ SimpleBuffer::EnsureCapacity]
You need to log in before you can comment on or make changes to this bug.