reed: Could you help find an owner for this one?

This medium+ severity security issue is a regression on trunk.

Please fix this asap. If you are unable to look into this soon, please revert your change.

- Your friendly ClusterFuzz

We're about 2 weeks away from M51 Beta launch. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and get it merged ASAP. Thank you.

M51 Beta is launching very soon! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on Apr-19th to make into the desktop Beta build cut. Thanks!

We're VERY close to M51 Beta candidate cut on Wednesday @ 5:00 PM PST. Any update here?

reed: can you please assist in finding an owner here? 

We cannot repro this locally - tried:

- local ASAN build
- CF ASAN build
- CF config
- CF repro instructions (run_gestures_on_device_local.py, etc)

No luck, running out of ideas.

Starting run number: 24
7 XSELINUXs still allocated at reset
SCREEN: 0 objects of 256 bytes = 0 total bytes 0 private allocs
DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs
CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 2 objects of 16 bytes = 32 total bytes 0 private allocs
GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 7 objects, 104 bytes, 0 allocs
2 PIXMAPs still allocated at reset
PIXMAP: 2 objects of 16 bytes = 32 total bytes 0 private allocs
GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 7 objects, 104 bytes, 0 allocs
4 GCs still allocated at reset
GC: 4 objects of 16 bytes = 64 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 5 objects, 72 bytes, 0 allocs
1 CURSORs still allocated at reset
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSOR_BITSs still allocated at reset
TOTAL: 0 objects, 0 bytes, 0 allocs
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
No crash found.

the posted stack-trace is 6 weeks old, and the file/line-no no longer make sense. If the bots can repro now, can we see newer traces?

The last changes to the 3x3 filter (prior to this bug report) seem to be on 2016-01-16. That seems to be much earlier than this bug was reported.

On 2016-03-01 I changed the bit of code where it chooses which proc to use and it is a bit of a mess.

It may be that the 3x3 filter is correct and I accidentally made it use the 3x3 filter when it shouldn't.

The fact that we can't locally repro it is a bummer.

Moving to RBS as M51 Beta candidate cuts today.

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

Latest run shows the crash here:

    AddressSanitizer: SEGV on unknown address 0x7f8eea483000

    void store(void* ptr) const { *(int*)ptr = _mm_cvtsi128_si32(fVec); }

Where ptr is in the buffer skia has allocated for the mipmap. The address looks like a page boundary, so I suspect it is the first write (attempt) after calling DiscardableMemory to allocate the block.

Skia requests a block 558M for the mipmap. If this ever gets purged (by discardable memory), then on the next draw it will request it again. Is that (large) value ever put us at risk of an over-commit, where the non-null returned address is not backed by pages, so we would SEGV when we actually try to write to them?

ClusterFuzz has detected this testcase as flaky and is unable to reproduce it in the original crash revision. Skipping fixed testing check and marking it as potentially fixed.

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

Fuzzer: cdiehl_peach
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x7f8a84552000
Crash State:
  void downsample_3_3<ColorTypeFilter_NUMBER>
  SkMipMap::Build
  SkMipMap::Build
  
Recommended Security Severity: Low

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=378207:378422

Minimized Testcase (0.28 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94DxW4ty5abukmEKEL16Kx5kVj94dNdIO8LkkuKZ3baqt5usgGtcjGyPSFkJNWw244mY9ikfC_4MNIPLGUKDwTXHDJRxHluJ_e9pibVID62eyoAmzmqIu2a7MR9WM1KVv6TvzTb6nPXD36VtyB2H9nf7fJv7Q

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.

A friendly reminder that M51 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by May 17. All changes MUST be merged into the release branch by 5pm on May 20 to make into the desktop Stable final build cut. Thanks!

We're getting closer to M51 Stable launch. Please update the bug with the current status. 

unassigning. afaik, this may be a flaky/bad allocation (via discardable memory), which was overcommitted, and therefore errors when we try to write to it. I do not see how skia can address this.

M51 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on May 20 to make into the desktop Stable final build cut. Thank you!

I suspect this may be related to https://bugs.chromium.org/p/chromium/issues/detail?id=610544

I plan to investigate 610544 so I'll go ahead and take this one as well. If I later find they aren't related I will update and unassign again.

where is the main bug for enabling GPU rasterization. This feature has caused major stability regressions and should be disabled, and put behind a finch for A/B stability experimentation. Who owns this feature?

Adding Eric, who has been working on enabling GPU rasterization. Eric also may have independently solved this bug as it may relate to another issue.

Adding vmpstr@ to see if he is familiar with if we may be accessing an unlocked image.

I have tried to reproduce this several times (45?) and have not been successful.
I think I may have possibly had one repro without a debugger attached or symbols.

I no longer think it is related to crbug.com/610544. That seemed to only be happening with GPU raster and this bug happened without GPU raster.

I will mark this bug unassigned as I mentioned in #25.

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

Fuzzer: inferno_sampler
Job Type: linux_asan_chrome_media
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x7fe185c18000
Crash State:
  void downsample_2_2<ColorTypeFilter_NUMBER>
  SkMipMap::Build
  SkMipMap::Build
  
Recommended Security Severity: Medium


Minimized Testcase (0.12 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94hQaO2Bh6jXv4V2-95G5_ILeCouqgspRkQyOb7lftz83Fs06E6Ae0DseLc1iz8YZnVY-BS9ihu3ixt7ndSqYpQ9DlNz094Q6B39wtq7D-ayrFDRVnJA0TuOXVTSEC1C48sf41iGyvdJqSEUFCUf9ErXMXpiw

Filer: inferno

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

Cblume@, please try with repro in c#30. That one is fully reproducible as per CF. Next week is Security FixIt, so your help is very appreciated here.

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

Fuzzer: cdiehl_peach
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x7f5798ca8000
Crash State:
  void downsample_3_3<ColorTypeFilter_NUMBER>
  SkMipMap::Build
  SkMipMap::Build
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=378207:378422

Minimized Testcase (0.30 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94jk-_8r0ZsxzFhL7tf8snbZtdVIRbH15jUHRTfmuPARye1KJbGzNX_0hA-7-cnTyfWwY8outB4GPKQLqOFdp4QI1Lw0B7kY0yCpeY-Ak1RnCAWQ0MR5pti65dZLlyK5wpLRHkgsNZOc4tWzpZRoWDkTbcBMg

Filer: inferno

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

This shouldn't block the M51 stable candidate. We can merge this in with a post-stable update.

cblume@ does not cycles to work on this.

Florin, can you please help here. We are in security fixit, so any help here is appreciated.

We're cutting M51 Stable RC on Tuesday, May 31st @ 1:00 PM PST. Pls make sure to land the fix and get it merged before then if you like to make it to next week M51 Stable release.

Removing release block - this shouldn't block the next release.

fmalita: Uh oh! This issue still open and hasn't been updated in the last 38 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

(Still cannot repro locally)

Someone more familiar with the Linux discardable memory impl should chime it, but I don't see anything fishy in Skia's mipmap code:

* the test uses a ridiculous 56321x7789 JPG (corrupted)
* ImageDecodeController allocates a whoppin 1.7GB DM to decode.  This is locked, for the subsequent scale.
* ImageDecodeController then allocates 4MB DM for the scaled image.  Still locked.
* IDC calls Skia to dowscale the image using kMedium_FilterQuality (mipmaps)
* Skia allocates another whoppin 584MB DM for mipmaps.  This is locked while we build the mipmaps.
* so we're up to something like 2.3GB locked DM
* Skia starts building the mipmap and segfaults while trying to write to one of the DM pages

Based on the above, I tend to agree with the theory in c#22: DM pages are severely overcommitted on resource-constrained systems (bots), the VM subsystem cannot fulfill a page fault and kills the process.

What is the CF bot configuration (available RAM, available shm, memory overcommit settings)?  Can someone get access to the system/logs to check for OOM clues?

#40: You might be able to test the hyothesis by setting a ulimit on Linux (`ulimit -v N`).

I did some debugging on the CF bots, where the issue is consistently reproducible (as a SIGBUS).

It appears that the theory in c#22 is correct, and the kernel is giving a SIGBUS on a write to the shared memory when there is no physical memory left to satisfy the /dev/shm file backing.

Marking this as WontFix, thanks to the people involved who investigated this.

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