based on creating reading of the regression revision range and changes, danakj@ it sounds like perhaps you might be able to help with this, perhaps related to your layer tree change in https://codereview.chromium.org/2270533002

It's crashing on:

  memcpy(shared_bitmap->pixels(),
         src,
         cc::SharedBitmap::CheckedSizeInBytes(pixel_image_size));

So the bitmap isn't valid, or image_data_->Map() failed or something.

I'm not sure under what conditions PPB_ImageData_Impl::Map() can fail, should we be checking for that?

I don't think a non-null SharedBitmap can have invalid pixels() and we check null for SharedBitmap so this must be the PPB_ImageData_Impl::Map() right?

ImageDataPlatformBackend::Map() can return null if dib_->GetPlatformCanvas() returns null, which happens for bad sizes. That looks likely here.

PepperGraphics2DHost::Init() does image_data_->Map() though and leaves image_data_ null if it failed., and I don't think ImageDataPlatformBackend::Map() can fail if it passed once.

Maybe Map() failed in init, and image_data_ is null, and Init() returned false, but we're still using the PepperGraphics2DHost for a texture layer or something..

The test case fails for me on linux with this DCHECK:

[13172:13195:0912/143933:FATAL:resource_provider.cc(609)] Check failed: size.width() <= max_texture_size_ (19456 vs. 16384)
#0 0x7faa9616dd1e base::debug::StackTrace::StackTrace()
#1 0x7faa9618ef9b logging::LogMessage::~LogMessage()
#2 0x7faa9303ce91 cc::ResourceProvider::CreateGLTexture()
#3 0x7faa9303cdce cc::ResourceProvider::CreateResource()
#4 0x7faa93047141 cc::ScopedResource::Allocate()
#5 0x7faa92fcba53 cc::TextureLayerImpl::WillDraw()
#6 0x7faa9309e392 cc::LayerTreeHostImpl::CalculateRenderPasses()
#7 0x7faa930a0306 cc::LayerTreeHostImpl::PrepareToDraw()
#8 0x7faa930da000 cc::ProxyImpl::DrawAndSwapInternal()
#9 0x7faa930d9daf cc::ProxyImpl::ScheduledActionDrawAndSwapIfPossible()
#10 0x7faa930552d9 cc::Scheduler::ProcessScheduledActions()
#11 0x7faa93054efd cc::Scheduler::OnBeginImplFrameDeadline()
#12 0x7faa9616e874 base::debug::TaskAnnotator::RunTask()
#13 0x7faa96199b55 base::MessageLoop::RunTask()
#14 0x7faa96199f28 base::MessageLoop::DeferOrRunPendingTask()
#15 0x7faa9619a34b base::MessageLoop::DoWork()
#16 0x7faa9619bb0a base::MessagePumpDefault::Run()
#17 0x7faa96199651 base::MessageLoop::RunHandler()
#18 0x7faa961c69a0 base::RunLoop::Run()
#19 0x7faa961fe250 base::Thread::Run()
#20 0x7faa961fe69e base::Thread::ThreadMain()
#21 0x7faa961f6d95 base::(anonymous namespace)::ThreadFunc()
#22 0x7faa962be184 start_thread
#23 0x7faa8d38e37d clone

For some reason the LSAN bots run with software compositing, I don't exactly match their behaviour.. but from the GPU compositing error, it's clear that we're simply making something enormous and we shouldn't.

With --disable-gpu I don't get a crash as this fuzzer says I should however.

Can a flash engineer comment on what we should do when the flash object is zoomed hugely and trying to use too many pixels?

Is crashing on OOM a bad solution?

Seems ok to me, it's what we do when we oom in other situations. Since I can't repro the fuzz error exactly I'm not totally sure how this is currently crashing though. :/

I think we don't need to crash (crashing the renderer because of the behavior of an untrusted plugin is rather rude), and instead just skip the update. But yes, we would need to understand what causes this.

piman would you prefer to just skip the update in PrepareTextureMailbox? Or change state at some higher level?

I think I remember investigating why this happens. The Map succeeds, but the memory isn't actually allocated at that point. When the memory is actually modified then allocation fails because too much shared memory (or total memory, I forget) is used, and that crashes the program. I think you could reproduce this by creating a huge file in /tmp and forcing all the pages to be allocated before running the test.

@#16: Assuming this is a situation we can detect, at the very least, early returning false from PrepareTextureMailbox (like we would do on a failure to allocate) seems better than crashing. Maybe failing PPB_ImageData_Impl::Init on more reasonable limits could be better (at least the plugin would know what's going on instead of silently failing).

@#17: does that condition cause a SIGSEGV though, as opposed to a SIGBUS or OOM kill?

danakj: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

ClusterFuzz has detected this issue as fixed in range 420859:421049.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6742160311582720

Fuzzer: attekett_dom_fuzzer
Job Type: linux_lsan_chrome_mp
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x7f5be67e3000
Crash State:
  content::PepperPluginInstanceImpl::PrepareTextureMailbox
  cc::TextureLayer::Update
  cc::LayerTree::UpdateLayers
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=144946:145047
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=420859:421049

Minimized Testcase (0.24 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv97b37TABo3nf7cFHGpJh_l0WFclvSyWya8tODdOmqLpSoutZkdwMm6ww0lGwyQEAnAtgsYrPyGAx0wzNMV1XA7v_nZKM48wdCn3iq0Wa9YXG12Kc3AzZtu60iJVshwFkG4VXIGYL-N-cMZhgVy4Iv_4U2uf_w?testcase_id=6742160311582720
<object
        id="default"
                type="application/x-shockwave-flash"
          width="1024" height="768"
          </noembed>
<script> 
var test0=document.getElementById("default")

setTimeout({
})
test0.style['zoom']='1\9';
</script>


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I'm not sure this is 

...actually fixed. But I'm also not sure of the priority. Is this actually a security issue? 

It's a null pointer crash when you use a crazy transform, where we try to write data to address 0-ish. Perhaps you can decide if that is a security issue better than I.

It's hard to write a fix when I fail to reproduce though which is why this sat here for a while.

It's not actually a null pointer we're trying to dereference. For example in the original report it was touching 0x7f5be67e3000. But my guess in comment #17 was that the address space was always reserved but had no memory backing it, so it'd only cause a crash.

CF detected as fixed, and hasn't come again.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.