Two related boundary defects let an image’s effective size be trusted without matching its validated backing. First, in ParamTraits<mozilla::wr::ImageDescriptor>::Read (gfx/layers/wr/WebRenderMessageUtils.h) the stride check was if (bpp <= 0 || stride / bpp < width). When width <= 0 (e.g. a negative or zero width from a compromised/buggy content process), stride / bpp < width is false, so a non-positive width passed validation while a non-zero stride was present. The patch adds width <= 0 to the rejection condition, so a descriptor that specifies a stride but a non-positive width is now rejected.

Second, ResourceCache::set_image_visible_rect (gfx/wr/webrender/src/resource_cache.rs) unconditionally overwrote image.descriptor.size = rect.size() (and image.visible_rect) for any image template. For non-blob images the size was already validated against the image’s data and stride, so letting the visible rect redefine size desynchronizes the descriptor from the bytes that back it. The patch returns early unless image.data.is_blob(), so only blob images — which are legitimately sized by their visible rect — have their size updated; raw/buffer templates keep the size their data and stride were validated against. The advisory’s “incorrect boundary conditions” matches the diff: both changes close paths where an image’s declared geometry could exceed/diverge from its validated backing, with the out-of-bounds read/write in the GPU process being the inferred security sink.

Both code paths run in the GPU/compositor process and consume data originating from the content process, so the relevant privilege is a compromised or misbehaving renderer (the advisory frames it as a sandbox escape). The diff proves two boundary-validation fixes that stop an image’s declared geometry from diverging from its validated backing; the concrete out-of-bounds read/write that this enables in a downstream consumer is the inferred sink — the diff shows the invariant restoration, not the faulting access. Rated moderate.