Bug 1841050 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36

Steps to reproduce:

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

When accessing the POC file from the browser, an out-of-bounds error occurs, leading to the termination of the GPU process.

In a typical environment, it works well, but in a VM, it may need the "webgl.force-enabled" option set to true to be triggered.


Actual results:

An out-of-bound bug occurs when calculating the sourcePixel in the BlitD24S8ToD32F function.
This function is as follows.

for (int row = 0; row < destArea.height; ++row)
{
    for (int column = 0; column < destArea.width; ++column)
    {
        ptrdiff_t offset         = row * sourceRowPitch + column * srcPixelStride;
        const float *sourcePixel = reinterpret_cast<const float *>(sourceData + offset);
        float *destPixel =
            reinterpret_cast<float *>(destData + row * destRowPitch + column * destPixelStride);
        Depth32FStencil8ToDepth32F(sourcePixel, destPixel);
    }
}

When calculating the sourcePixel, the offset can be larger than the size of the sourceData, resulting in an out-of-bound bug.

sourceData = width*height*srcPixelStride
  - width and height are values that can be set in the renderbufferStorage API.
  - srcPixelStride is set to 8 when using DEPTH32F_STENCIL8 foramt in the renderbufferStorage API.

offset = row*sourceRowPitch+column+srcPixelStride
  - row = dstY0-dstY1
    - dstY0 and dstY1 are values that can be set in the blitFramebuffer API.
  - sourceRowPitch = width*srcPixelStride
    - width is value that can be set in the renderbufferStorage API.
    - srcPixelStride is set to 8 when using DEPTH32F_STENCIL8 foramt in the renderbufferStorage API.
  - column = dstX0-dstX1
    - dstX0 and dstX1 are values that can be set in the blitFramebuffer API.

The size of the sourceData is affected by the width and height values set by the renderbufferStorage API.
If there is no validation for row or column values when calculating offset, an out-of-bound bug will occur.
In fact, there is a check of values for row and column. But this check is wrong.
Row must be verified to be less than width and column less than height. At this time, width and height must be values set by the renderbufferStorage API.
However, row is compared to the width of the canvas object and column is compared to the height of the canvas object.
Therefore, if you set the width and height of the canvas object large, the offset increases a lot.


Expected results:

This bug allows for inserting values obtained through an out-of-bound read into the destPixel. Therefore, this results in information leak.
Revision 1 by
on 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36

Steps to reproduce:

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

When accessing the POC file from the browser, an out-of-bounds error occurs, leading to the termination of the GPU process.

In a typical environment, it works well, but in a VM, it may need the "webgl.force-enabled" option set to true to be triggered.


Actual results:

An out-of-bound bug occurs when calculating the sourcePixel in the BlitD24S8ToD32F function.
This function is as follows.
```javascript
for (int row = 0; row < destArea.height; ++row)
{
    for (int column = 0; column < destArea.width; ++column)
    {
        ptrdiff_t offset         = row * sourceRowPitch + column * srcPixelStride;
        const float *sourcePixel = reinterpret_cast<const float *>(sourceData + offset);
        float *destPixel =
            reinterpret_cast<float *>(destData + row * destRowPitch + column * destPixelStride);
        Depth32FStencil8ToDepth32F(sourcePixel, destPixel);
    }
}
```
When calculating the sourcePixel, the offset can be larger than the size of the sourceData, resulting in an out-of-bound bug.

```javascript
sourceData = width*height*srcPixelStride
```
  - width and height are values that can be set in the renderbufferStorage API.
  - srcPixelStride is set to 8 when using DEPTH32F_STENCIL8 foramt in the renderbufferStorage API.

```javascript
offset = row*sourceRowPitch+column+srcPixelStride
```
  - row = dstY0-dstY1
    - dstY0 and dstY1 are values that can be set in the blitFramebuffer API.
  - sourceRowPitch = width*srcPixelStride
    - width is value that can be set in the renderbufferStorage API.
    - srcPixelStride is set to 8 when using DEPTH32F_STENCIL8 foramt in the renderbufferStorage API.
  - column = dstX0-dstX1
    - dstX0 and dstX1 are values that can be set in the blitFramebuffer API.

The size of the sourceData is affected by the width and height values set by the renderbufferStorage API.
If there is no validation for row or column values when calculating offset, an out-of-bound bug will occur.
In fact, there is a check of values for row and column. But this check is wrong.
Row must be verified to be less than width and column less than height. At this time, width and height must be values set by the renderbufferStorage API.
However, row is compared to the width of the canvas object and column is compared to the height of the canvas object.
Therefore, if you set the width and height of the canvas object large, the offset increases a lot.


Expected results:

This bug allows for inserting values obtained through an out-of-bound read into the destPixel. Therefore, this results in information leak.

Back to Bug 1841050 Comment 0