Chromium

jrprice@ can you check if this one has security implications? If not I can remove view restrictions.

Reduced to:

@group(0) @binding(0) var image_dup_src: texture_storage_1d<r32uint,read>;
@group(0) @binding(1) var image_dst: texture_storage_1d<r32uint,write>;

// for #1307 loads with ivec2 coords.

Note: the comment is important, as this seeds the side-band fuzzer data.

This looks like the SPIR-V writer is not handling the readonly_and_readwrite_storage_textures feature correctly.
I think it's highly unlikely that this is security impacting, but I'll let jrprice decide.

Fix up for review: https://dawn-review.googlesource.com/c/dawn/+/190621

can you check if this one has security implications?

After discussion in our team, we believe there is the potential that passing invalid SPIR-V to a Vulkan driver could cause unknown issues that may include security-impacting effects. We are not aware of any specific exploit that can be triggered for this particular case, but cannot decisively rule out such exploits at this time. This particular bug is limited to Android devices.

mpdenton@ please LMK if you any need more information to assess the severity. I can take care of merging the bug fix back to whichever branches will require it based on the perceived severity.

Thanks for the analysis! I'll mark this as S1, but as an aside could you elaborate what you think the "unknown issues that may include security-impacting effects" might be?

There are no more scheduled releases for M124/M125 - removing label

1. Which CLs should be backmerged? (Please include Gerrit links.)

https://dawn-review.googlesource.com/c/dawn/+/190621

2. Has this fix been verified on Canary to not pose any stability regressions?

Yes.

3. Does this fix pose any potential non-verifiable stability risks?

No.

4. Does this fix pose any known compatibility risks?

No.

5. Does it require manual verification by the test team? If so, please describe required testing.

No.

mpdenton@:

as an aside could you elaborate what you think the "unknown issues that may include security-impacting effects" might be?

The GPU driver that we are handing this invalid SPIR-V too is an opaque blob, some of which is in user mode and some in kernel mode. Although this particular example is pretty benign and I wouldn't imagine there is any real security issue here, it's hard to know for sure exactly what assumptions might be violated in the driver, leading to bad internal state and subsequent issues. I don't have a specific, exploitable side effect in mind though.

Thanks, so in the GPU process the process goes WGSL -> SPIR-V -> usermode gpu driver -> kernel mode gpu driver? And normally, we expect the WGSL -> SPIR-V conversion to produce a sufficiently constrained and "valid" SPIR-V output such that GPU drivers, which are normally relatively soft targets, should be somewhat protected from untrusted inputs?

we expect the WGSL -> SPIR-V conversion to produce a sufficiently constrained and "valid" SPIR-V output such that GPU drivers, which are normally relatively soft targets, should be somewhat protected from untrusted inputs?

Correct. Vulkan, the API that the GPU drivers implement, does minimal (if any) validation, so it's on us to make sure we only use it in valid ways.

Merge approved for M126! Please cherry pick the fix to branch 6478 by Thursday June 13th EOD MTV time to get this fix into the next stable respin

Congratulations, gelatin! While we were able to make a potentially security relevant change to mitigate potential exploitation of this issue in the GPU process, there was no security impact demonstrated by or able to be gleaned from the information in your report; therefore, we are extended a reduced reward for this report. Thank you again for your efforts!

This bug has been closed for more than 14 weeks. Removing issue access restrictions.