This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

reed@, could you please help to find an owner?

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

reed: 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

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Not seeing a smoking gun Skia-side, and no changes in this area recently..wondering if this is really being caused by our code.

siggi@, I wonder if you can help find the owner for this. Thanks!

Seb, the block info doesn't make sense to me here. The sum of the user size and the start address exceeds 32 bits. Is there perhaps an integer overflow in the heap allocation implementation?

Report for c:\clusterfuzz\slave-bot\inputs\crash-stacks\minidump-00007244-00009992-341713859.dmp
Bad access information:
  feature_set: 1
  corrupt_ranges_reported: 0
  asan_parameters: common::AsanParameters
  user_size: 0y110000000000000000000000011100 (0x3000001c)
  milliseconds_since_free: 0
  heap_type: kWinHeap
  corrupt_range_count: 0
  access_size: 0
  free_tid: 0
  free_stack_size: 0 
  corrupt_ranges: (null)
  heap_is_corrupt: 0
  alloc_stack: [62] 0x70aaa2ae Void
  shadow_memory: [512]  ""
  alloc_stack_size: 0x39 9
  header: 0x7fff1020 Void
  shadow_info: [128]  ""
  error_type: CORRUPT_BLOCK
  free_stack: [62] (null)
  analysis: agent::asan::BlockAnalysisResult
  alloc_tid: 0x2708
  state: 0y00
  location: 0x7fff1030 Void
  context: _CONTEXT
  crash_stack_id: 0x5d93d4a7
  access_mode: ASAN_UNKNOWN_ACCESS
  block_info: agent::asan::AsanBlockInfo
  corrupt_block_count: 0

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure all fixes are ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16.

Assigning to Seb, as this looks like a SyzyASAN bug. I could have sworn I assigned this to Seb already in #13.

I'm looking at this.

Sorry for the delay, I was busy hunting down another P0, I'm back on this one now.

This is effectively a bug in SyzyAsan, removing the ReleaseBlock and the Security labels for now.

The problem is that the SyzyAsan block header only support allocations < 1 GB (we only keep 30 bits to store the block size), but in this test we're allocating a 1.75 GB block (0x7000001c bytes), which succeed but the first bit  of the block_header->body_size field gets truncated (we store a value of 0x3000001c) and so when comes try to free the block we use an invalid size to compute the block's checksum and it makes us suspect that this block is corrupt.

We can fix it by adding one bit to the BlockHeader.block_size field or by preventing from allocating a block > 1GB. I'll try to go with the first suggestion.

Thanks Seb - is that also the case for  issue 633470 ?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8df5e216e947e285bad1933054308159f9954b43

commit 8df5e216e947e285bad1933054308159f9954b43
Author: sebmarchand <sebmarchand@chromium.org>
Date: Tue Nov 29 20:44:18 2016

Roll Syzygy DEPS to v0.8.24.0

Changelog:
[ea4e050] SyzyAsan - Support the allocations with a size > 1GB.
[a1f6aa6] SyzyAsan - Remove support for the nested allocations.

BUG= 656554 

Review-Url: https://codereview.chromium.org/2537223002
Cr-Commit-Position: refs/heads/master@{#435076}

[modify] https://crrev.com/8df5e216e947e285bad1933054308159f9954b43/DEPS

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