Debian Patches
Status for libskia/146.20260602~git.3476902+dfsg-4
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| build-files | Debian-specific makefile. | Filip Strömbäck <filip@fprg.se> | not-needed | |||
| unsupported-attributes | Remove unsupported annotations. | Filip Strömbäck <filip@fprg.se> | not-needed | |||
| vk_malloc-location | Use system library of vk_mem_alloc.h. | Filip Strömbäck <filip@fprg.se> | not-needed | |||
| loong-build | Patches to make loong64 build work with GCC. | Filip Strömbäck <filip@fprg.se> | yes | |||
| CVE-2026-5870 | Use SkSafeMath to prevent overflow in pixel offset calculations. The trim methods in SkReadPixelsRec and SkWritePixelsRec now use SkSafeMath to calculate the offset for fPixels. This addresses potential integer overflows when computing the y and x offsets and their sum. Additionally, a check for fInfo.minRowBytes() == 0 is added, as minRowBytes() returns 0 on overflow. If any overflow occurs during offset calculation, trim will now return false. See linked bug for potential security issue that motivated this. And see (sorry internal only) go/code-terracotta-review-explainer for evaluting this phase (1) patch. |
Stephen Nusko <nuskos@google.com> | yes | upstream | 2026-03-25 | |
| CVE-2026-7920 | Make local optimized copy of program when creating SkRP version As per the linked bug, there could be a problem if the gpu backend tried to use a compiled runtime effect at the same time as the cpu backend made its first call to getRPProgram(). This could result in the fBaselineProgram being mutated out from under the gpu backend's version. This makes an optimized copy of the existing program to then convert to SkRasterPipeline. By setting optimize to true and a non-zero inlining limit, compiler.convertProgram will call the inliner and remove unused functions (as well as other things like unused local/global variables). To prevent further mutation of fBaseProgram, I made it be pointer to const (I'd initially been puzzled how a const getRPProgram could be mutating it, but only the pointer was const). Performance change looks negligible (parsing is pretty quick): ``` $ out/Release/nanobench_baseline --match sksl_skrp Timer overhead: 23.5ns curr/maxrss loops min median mean max stddev samples config bench 92/90 MB 3 5.35µs 5.38µs 5.38µs 5.45µs 0% █▅▁▃▃▄▄▂▃▃ nonrendering sksl_skrp_tiny 92/90 MB 3 14.7µs 14.9µs 15.1µs 17.5µs 6% █▂▁▁▁▁▁▁▁▁ nonrendering sksl_skrp_small 92/90 MB 1 125µs 132µs 135µs 164µs 9% █▅▃▂▂▁▂▁▁▄ nonrendering sksl_skrp_medium 92/90 MB 1 321µs 338µs 339µs 364µs 5% █▆▃▂█▄▂▁▅▂ nonrendering sksl_skrp_large $ out/Release/nanobench_with_change --match sksl_skrp Timer overhead: 23.5ns curr/maxrss loops min median mean max stddev samples config bench 92/90 MB 3 5.62µs 5.64µs 5.64µs 5.69µs 0% █▂▄▄▃▃▄▁▅▃ nonrendering sksl_skrp_tiny 92/90 MB 4 14.8µs 14.9µs 15.3µs 17.1µs 5% █▂▁▁▅▁▁▁▁▁ nonrendering sksl_skrp_small 92/90 MB 2 125µs 130µs 131µs 154µs 7% █▃▂▂▂▁▁▂▁▃ nonrendering sksl_skrp_medium 92/90 MB 1 322µs 344µs 342µs 369µs 5% █▆▅▃▂▁▇▄▂▃ nonrendering sksl_skrp_large ``` |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-04-27 | |
| CVE-2026-7923 | Avoid removing too many stack entries in SkRP during discard_stack Consider an sksl snippet like: ``` half4 main(float2 xy) { float4 v = float4(xy.x, -1.0, -2.0, -3.0); v = abs(v); return half4(v); } ``` this could be turned into (unoptimized) instructions like [1] ``` store_src_rg xy = src.rg init_lane_masks CondMask = LoopMask = RetMask = true copy_slot_unmasked v(0) = xy(0) copy_constant v(1) = 0xBF800000 (-1.0) copy_constant v(2) = 0xC0000000 (-2.0) copy_constant v(3) = 0xC0400000 (-3.0) copy_4_slots_unmasked $0..3 = v # unnecessary bitwise_and_imm_4_ints $0..3 &= 0x7FFFFFFF copy_4_slots_unmasked v = $0..3 load_src src.rgba = $0..3 ``` ( the bitwise_and_imm_4_ints instruction is the abs() part, masking off the sign bit) We can optimize cases where we push to the stack (e.g. the copy_4_slots_unmasked), do an operation (the &=) and then pop the value off the stack into just doing the operation w/o involving the stack. (We might have to push the result to the stack for further use). ``` ... copy_constant v(3) = 0xC0400000 (-3.0) bitwise_and_imm_4_ints v &= 0x7FFFFFFF copy_4_slots_unmasked $0..3 = v load_src src.rgba = $0..3 ``` There was a bug in the optimization where we removed *all* the slots for an instruction (4 in this case because it's a float4) even though the call was discard_stack(1). This would be followed up by a call to discard_stack(3) (the remainder of the previous instruction's stack) and we'd underflow the stack. Problematic sksl: ``` half4 main(float2 xy) { float4 v; v.x += xy.x; (v = abs(v)).xyz; # drop 1 channel (the .w) return half4(v); } // This was in the output bitwise_and_imm_4_ints v &= 0x7FFFFFFF copy_4_slots_unmasked ExternalPtr(0..3) = v load_src src.rgba = ExternalPtr(0..3) ``` where ExternalPtr is referring to memory outside any variables, uniforms, or the temporary stack. Yikes! I'll keep that in mind for the future. Anyway, for the fix, we'll only remove N slots if the previous call was N slots wide. [1] e.g. bazel build //tools/skslc && bazel-bin/tools/skslc/skslc input.sksl output.skrp |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-04-27 | |
| CVE-2026-7949 | Use a local data copy for strike deserialization The readStrikeData() input is volatile (shared memory) and untrusted. To avoid time-of-check to time-of-use issues during deserialization, always make a copy when transitioning to internal/non-volatile APIs. This is similar to the other defensive copies used in Chromium's cc/paint_op deserialization, e.g. [1]. [1] https://source.chromium.org/chromium/chromium/src/+/main:cc/paint/paint_op_reader.cc;drc=9c91b2494d4bf0a2d33b5985f7d1af79e72146f2;l=329 |
Florin Malita <fmalita@google.com> | yes | upstream | 2026-03-27 | |
| CVE-2026-8510 | [sksl] Check allowSkSL for SkRuntimeImageFilter::CreateProc Since SkRuntimeImageFilter doesn't create its runtime shaders until actually evaluating the image filter, SkRuntimeShader's CreateProc was not being reached; it must be responsible for validating allowSkSL. Updates the unit test to confirm that all sources of runtime effects in drawables are detected when allowSkSl is false. |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-04-21 | |
| CVE-2026-8579 | Validate sizes in mskp reading and SkTableMaskFilter The max dimension for mskps is approximately the sqrt of INT32_MAX which felt "big enough" |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-03-30 | |
| CVE-2026-9892 | Report and handle failure for inlineUpload(...) calls * The bug associated with this change called out that we should not attempt to perform an upload on an externally-owned secondary command buffer. * Exiting early does not appropriately signal that an upload failed, so modify `GrOpsRenderPass::inlineUpload(...)` base class to return a bool indicating success or failure. Upon failure, do not attempt the associated immediate draw call and report that the draw failed. * To maintain current behavior, have `inlineUpload(...)` return true in nearly all cases except that identified in the associated bug. |
Nicolette Prevost <nicolettep@google.com> | yes | upstream | 2026-05-20 | |
| CVE-2026-9893 | Null out VkShaderModule handles when destroying them. | Greg Daniel <egdaniel@google.com> | yes | upstream | 2026-05-18 | |
| CVE-2026-9909 | Identify overflow in SkGlyph allocation earlier Follow-up to https://review.skia.org/1209996 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-04-27 | |
| CVE-2026-9923 | [graphite] Fix a security issue in GlobalCache::findGraphicsPipeline | Robert Phillips <robertphillips@google.com> | yes | upstream | 2026-04-23 | |
| CVE-2026-9981 | [ganesh] Use & when testing for input attachment self-dep Other than these two sites, kForInputAttachment and kForNonCoherentAdvBlend are not treated as mutually exclusive. When using only == kForInputAttachment, the layout and bindings wouldn't apply correctly for a renderpass that was using both forms of self dependencies. |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-05-21 | |
| CVE-2026-9983 | Fix pathops bug with linked lists in SkOpCoincidence I added some logging to SkOpCoincidence::fixUp and ::release and, with the new test case (which has multiple coincidences [1]), observed ``` ``` As per the linked bug, this leads to a faulty state because the old head pointer 0x...7378 is being used after it was "released". I could not get ASAN to fire on this but it is worth fixing for correctness and consistency. My change fixes that particular issue and adds some asserts to avoid this happening again. I also rewrote some do while loops to avoid iffy behavior where we were releasing coin and then for the next iteration still calling coin->next(). This worked because we had an SkArenaAlloc and that memory wasn't "fully" released. [1] a coincidence is an overlap between two path segments that lasts for more than a single point. e.g. two squares sharing an edge. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-18 | |
| CVE-2026-9998 | Fix for integer wraparound in sksl I found the ES 2 spec [1] helpful for reference here. The calculate_count_neq_int is not strictly necessary (I was unable to find a case that tricked the existing floats with ints), but I like the refactoring and it mirrors the gt/lt cases nicely. [1] https://registry.khronos.org/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-20 | |
| CVE-2026-10009 | Avoid overflow and timeout in SkPathWriter::assemble I was unable to make a test case that caused an overflow and didn't timeout, but I think the possibility exists for both. This removes that, adds a few defensive asserts, and makes one assert actually checked at runtime, just to be safe. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-19 | |
| CVE-2026-10011 | [ganesh] Require glyph padding to use linear sampling | Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-05-19 | |
| CVE-2026-10012 | [graphite] ensure drawlist resources are cleared on failure | Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-05-18 | |
| CVE-2026-13781 | Restrict deserial types further in SkGlyph and SkCustomTypeface Importantly, we don't want typefaces or textblobs in SkPictureBackedGlyphDrawable. In fact, we can look at the code used to make the drawables by our various backends [1][2][3][4] and see we only draw paths and use paints. Thus, we can restrict deserializing these to just those (and the helper tags). The SVG fonts could be a bit more complex [5] but chromium doesn't use those (SkGraphics::SetOpenTypeSVGDecoderFactory is never called) See also http://graphviz/#57cc93d0c3c73546055bec64fa8e27cb [1] https://skia.googlesource.com/skia/+/9da67e212e59fbe4f144a92315ca6f8b876c9c01/src/ports/SkFontHost_FreeType_common.cpp#1567 [2] https://skia.googlesource.com/skia/+/9da67e212e59fbe4f144a92315ca6f8b876c9c01/src/ports/SkFontHost_FreeType_common.cpp#1078 [3] https://skia.googlesource.com/skia/+/9da67e212e59fbe4f144a92315ca6f8b876c9c01/src/ports/SkScalerContext_win_dw.cpp#677 [4] https://skia.googlesource.com/skia/+/9da67e212e59fbe4f144a92315ca6f8b876c9c01/src/ports/SkTypeface_fontations.cpp#1336 [4] https://skia.googlesource.com/skia/+/9da67e212e59fbe4f144a92315ca6f8b876c9c01/modules/svg/src/SkSVGOpenTypeSVGDecoder.cpp#160 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-27 | |
| CVE-2026-13841 | [graphite] Drop excessively large gradient draws This skips recording draws with more than 1M color stops, primarily as a way to avoid worrying about overflowing during intermediate calculations. We can increase it if necessary, but hopefully this is healthy enough no one is trying to make shaders this large. This also skips recording draws when the FSM has maxed out its allocatable size for a single buffer. Given how large that is, we shouldn't encounter it in the wild but this lets us fail semi gracefully. If needed, we can revisit by either flushing the entire Recorder when reaching a limit, or by allowing a recording to use multiple buffers |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-05-22 | |
| CVE-2026-13820 | [graphite] Ref count large gradient shaders in FloatStorageManager This also removes the unique ID from SkShaderBase as the FSM was the only system that relied on it. |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-05-22 | |
| CVE-2026-13885 | Use exclusive mutex in SkFontMgr_android_ndk.cpp SkLRUCache::find() is mutating so a shared mutex doesn't actually buy us anything here. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-28 | |
| CVE-2026-13971 | Address potential MSAN issue in SkScalerContext If malformed data was passed to SkStrikeClient, an unexpected mask would pass through asserts in a release build and lead to a mask being allocated that was 4x bigger than what was written to. To defend against this problem, we 1) reject masks that aren't of the three formats SkScalerContext::GenerateImageFromPath expects; 2) zero out the whole mask, regardless of how big it is instead of relying on how big an A8 mask would be. Additionally, I noticed that in the intermediateDst case (e.g. for LCD text when we draw into an A8 and then later unpack it to be LCD16) we weren't zeroing that intermediate buffer which could be a problem if the glyph itself was small (but the bounds were corrupted to be big). Thus, we zero that intermediate A8 buffer too. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-05-29 | |
| CVE-2026-14387 | [graphite] Cache single-buffer BindGroups on DawnBuffer * This follows the Vulkan backend in caching single-buffer bind groups on to Buffer implementations. This allows us to remove DawnResourceProvider's special caching of single-texture bindgroups and findOrCreateSingleTextureSamplerBindGroup(...). * The DawnCommandBuffer instead defines the bind group entries for single-texture groups and uses the generic createBindGroup(...) method. |
Nicolette Prevost <nicolettep@google.com> | yes | upstream | 2026-05-13 | |
| CVE-2026-14389 | Fix potential integer overflows in SurfaceContext using SkSafeMath | Greg Daniel <egdaniel@google.com> | yes | upstream | 2026-05-04 | |
| CVE-2026-14410 | [graphite] correctly advance index in drawEdgeAAImageSet | Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-05-19 | |
| CVE-2026-14414 | Reland "Reconstruct subRun bounds from glyphs" * Allow subRuns which are drawn with drawable or path rendering to exit gracefully instead of failing. * Remove erroneous SFINAE This reverts commit c480ba2eb2eba29a78b28b188cf2e8a3fb44dd49. Original change's description: > Revert "Reconstruct subRun bounds from glyphs" > > This reverts commit f93ed13d77fb28b1ab5c058c10bda3049ccbc5f5. > > Reason for revert: SkRemoteGlyphCacheTest failures and build failures > > ../../../../../skia/tests/SkRemoteGlyphCacheTest.cpp:193:37: error: unused function template 'get_container_ptr' [-Werror,-Wunused-template] > 193 | const sktext::gpu::SubRunContainer* get_container_ptr(const T& t) { > | ^~~~~~~~~~~~~~~~~ > ../../../../../skia/tests/SkRemoteGlyphCacheTest.cpp:212:37: error: unused function template 'get_container' [-Werror,-Wunused-template] > 212 | const sktext::gpu::SubRunContainer* get_container(T* slugImpl) { > | ^~~~~~~~~~~~~ > 2 errors generated. > > and > > > ../../../../../skia/tests/SkRemoteGlyphCacheTest.cpp:660 Dst subrun is null for TransformedMaskSubRun [SkRemoteGlyphCache_SubRunBoundsReconstruction, OpenGL] > > Original change's description: > > Reconstruct subRun bounds from glyphs > > > > * Reconstruct the bounds of a subRun after deserialization instead of packaging onto the VertexFiller. > > > > * An attacker could create a VertexFiller with creation bounds that did not contain its glyphs but were entirely contained within the current clip, enabling to the glyphs to ignore the creation bounds clip and sample from stale scratch textures > > > > Bug: b/513948227 > > Change-Id: Ib4902657e6a50dd5675db4d73a1576b77c4ce88e > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1239916 > > Commit-Queue: Thomas Smith <thomsmit@google.com> > > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > > Bug: b/513948227 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Change-Id: Ide85466e17b870d2cc738bd25602d6cbf65d332b > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1249276 > Auto-Submit: Michael Ludwig <michaelludwig@google.com> > Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> |
Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-05-29 | |
| CVE-2026-14419 | Reland "[graphite] BufferSubAllocator respects failed mapping on reset" * `getMappedUniformBuffer` was changed after M148 but before M149. This caused comments in the unit test to be wrong, causing M148 cherry pick to fail CQ. * Change the unit test to instead use `getMappedIndexBuffer`, which is stable across the relevant releases, and has been confirmed to trigger the bug. * These changes purely affect the unit test and not the fix itself. This reverts commit c329e877d1848877d459999a4ed43b3728892b7b. Original change's description: > Revert "[graphite] BufferSubAllocator respects failed mapping on reset" > > This reverts commit e7bff78bf5d2994f627742aaf5040b2ba55c4475. > > Fails clang-tidy > > Original change's description: > > [graphite] BufferSubAllocator respects failed mapping on reset > > > > Bug: b/516981393 > > Change-Id: If6837e26ee520ad34c8df46a34850220ec5b538c > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1247536 > > Commit-Queue: Thomas Smith <thomsmit@google.com> > > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > > Bug: b/516981393 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Change-Id: I8cf69a8ba2ff318aab65033af821954e4493e5cb > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1249556 > Auto-Submit: Thomas Smith <thomsmit@google.com> > Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> |
Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-05-29 | |
| CVE-2026-14427-a | Reject Slugs that have creationMatrix with perspective This shouldn't happen during normal use [1] but if the data is corrupted, there are some assumptions that can can cause issues, like the ones linked in the bug. This rejects those and turns one assert into an actual runtime check to provide defense in depth. [1] https://github.com/google/skia/blob/9eecbdc30f7da675edab96974b23174a9d521e0c/src/text/gpu/SubRunContainer.cpp#L1578-L1581 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-06-05 | |
| CVE-2026-14427-b | Use an assert release on stride length Follow-up to https://review.skia.org/1256016 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-06-08 | |
| CVE-2026-14429 | Avoid improper mask formats for SDFT runs SDFTSubRun has a hard assumption of the kA8 mask format and if the vertex filler differs, there will be a memory mismatch. This catches it when deserializing the Slug and changes the debug-only assert to be runtime to make sure we don't miss other places. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-06-08 | |
| CVE-2026-78914 | [ganesh] Fully clear initial stencil bits when stencil clear is a draw There is a driver bug where clearing stencil requires a manual draw (performStencilClearsAsDraws). Previously, we called internalStencilClear() which only zeroed the stencil clip bit (fWriteMask == clipBit). However, the initial stencil clear must also zero the user bits. Otherwise, stencil-then-cover path renderers might read undefined stencil contents on their first use. This change records a full-surface draw that zeroes both clip and user bits when clearing as draw. |
Greg Daniel <egdaniel@google.com> | yes | upstream | 2026-07-22 | |
| CVE-2026-79112 | [Security] Added checks to MakeFromBuffer for Cluster size If a renderer is compromised, an OOB cluster index can be provided, which would then lead to an OOB memory read if it underflows / overflows. The solution is to check each glyph within the clusters array (buf->clusters) when deserializing such taht all cluster indices are not greater than textsize. Otherwise return nullptr. |
Alexis Cruz-Ayala <alexisdavidc@google.com> | yes | upstream | 2026-07-17 | |
| CVE-2026-79147 | Propagate protectedness to SkPictureShader draws This change seems harmless and is more correct. Basically, the protected-ness of the backing surface is propagated to the internal image created for a PictureShader. This is relevant if the SkPicture contains protected content. |
Robert Phillips <robertphillips@google.com> | yes | upstream | 2026-06-30 | |
| CVE-2026-17757 | Fix Ganesh stencil UMR When, for a given OpsTask, the stencil ops are discard/store there was a possibility of uninitialized values to creep into the stencil buffer. This CL reduces the cases in which discard will be used, mapping the problematic cases to clear/store. |
Robert Phillips <robertphillips@google.com> | yes | upstream | 2026-06-25 | |
| CVE-2026-15766 | Check clipped renderpass bounds against cleared stencil area * If only a portion of the stencil attachment is cleared, we should not mark the entire attachment as cleared. This CL makes it such that we check which area has most recently been cleared to make an informed decision. |
Greg Daniel <egdaniel@google.com> | yes | upstream | 2026-06-29 | |
| CVE-2026-15774 | Fix Use-After-Free in SubRunAllocator The destruction order of `std::tuple` members is not specified by the C++ standard. This is the root cause of a Use-After-Free (UAF) in SubRunAllocator. Replacing the tuple with a custom struct resolves the issue by guaranteeing the correct destruction order. The Bug: During deserialization of a Slug (specifically in SlugImpl::MakeFromBuffer), if the input buffer is invalid or corrupted, Skia detects this and returns nullptr early. This early return destroys the temporary return value. In the old code (using `std::tuple`), `SubRunInitializer` (index 0) was destructed first and freed the backing memory. `SubRunAllocator` (index 2) was destructed next. Its destructor (~BagOfBytes) then attempted to access fEndByte (which points inside the freed memory), resulting in a UAF (read) followed by a wild-free or double-free. The Fix: We replaced the `std::tuple` with a custom helper struct `AllocateAndArenaResult`: struct AllocateAndArenaResult { SubRunInitializer<T> initializer; // Destructed last int totalMemorySize; SubRunAllocator alloc; // Destructed first }; Since struct members are guaranteed to be destructed in the reverse order of their declaration, declaring `alloc` last guarantees it is destructed before `SubRunInitializer` frees the memory. Additionally, this CL refactors `SubRunInitializer` to use `std::unique_ptr` with a custom deleter to manage the raw memory, removing the need for a manual destructor and making the ownership transfer explicit via `release()`. |
Arthur Sonzogni <arthursonzogni@chromium.org> | yes | upstream | 2026-07-03 | |
| CVE-2026-16417 | [ganesh] prevent stale readbacks * Ganesh's SurfaceContext::readPixels did not consider whether the content it was attempting to readback was successfully rendered or not, leading to a scenario where stale texture data could potentially be readback. * Add some state tracking so that a failed flush is propagated out of the drawing manager and to the surface context |
Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-07-16 | |
| CVE-2026-17653 | [graphite] Use stable collection for static bindings Since the layouts are passed by pointer in the `nextInChain` field, their addresses need to stay valid until the BindGroupLayout is created. With vector, if it ever grew, that would not remain the case. Since there are usually only 0 to 1 immutable samplers, this likely never happened (and also why it uses a built-in storage for 1). Also removes the include for vector and uses TArray (we had been mixing both throughout the file). |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-06-12 | |
| CVE-2026-17702 | [Ganesh] If a resolve task fails to execute unwind the dirty tracking. If a flush fails for some reason then we can get in an inconsistent state with our dirty rect tracking for msaa resolves and mip maps. This happens because we immediately update the proxies tracking of these values when we recording a resolve task. But if that resolve task never executes for some reason then we can end up in a bad state. This changes makes it so that if a resolve task is ended without ever executing, then it resets the proxies state to what it was before. Technically if the draws before the resolve also never execute we will now be marking a region dirty that isn't neccessarily dirty. This could cause an extra resolve on future draws but is safe. However in practice is flushes fail, clients will usually either tear everything down (and thus it doesn't matter), or repeat the same draws again (which would end up with the same resolve rect anyways). So this possible extra resolve doesn't have a large real world impact. |
Greg Daniel <egdaniel@google.com> | yes | upstream | 2026-07-17 | |
| CVE-2026-17712 | Resolved a Data Race on fStream in SkTypeface_Mac There was a data race in SkTypeface_Mac where `onOpenStream` and `onOpenExistingStream` would race to read/write `fStream`. While `onOpenStream` would begin initializing `fStream` on one thread, a separate thread could be calling `onOpenExistingStream` to try to read `fStream` before it was done initializing. The issue was resolved by applying a mutex on `fStream`. The cl introducing this bug (https://skia-review.git.corp.google.com/c/skia/+/204720) was focused on caching the typefaces received with a global process wide `gTFCache` to save on performance and memory. The issue arose in that since the SkTypeface_Mac could be accessed across threads, it became thread unsafe. A test was added to this CL but removed as it was too large and took too long. It helps us keep it in the patch history for reference. |
alexisdavidc <alexisdavidc@google.com> | yes | upstream | 2026-06-12 | |
| CVE-2026-17745 | Reland "[Ganesh] TextureOp quad illegal memory access" This reverts commit 5e976cb2f034067e006ec8db2889791f0d4eb443. Reason for revert: The unit test was exceeding maxTextureSize on some devices Original change's description: > Revert "[Ganesh] TextureOp quad illegal memory access" > > This reverts commit 148b2b1948019f8f89435b4df7d598224a2ab0e1. > > Reason for revert: Crashing on some Android devices > > Failure Link: <LINK TO FAILURE> > > Original change's description: > > [Ganesh] TextureOp quad illegal memory access > > > > This CL fixes an overflow in the number of allowed quads in a TextureOp. It works on two fronts: > > It conservatively tracks the number of quads (incl. perspective) > > It prevents a fast path when there possibly might be an overflow. > > > > Bug: b/500172224 > > Change-Id: Icd92ed5c80d81cdbfea8d2463407cc48a0a32843 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1262376 > > Commit-Queue: Robert Phillips <robertphillips@google.com> > > Reviewed-by: Michael Ludwig <michaelludwig@google.com> > > Bug: b/500172224 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Change-Id: Ic4ea8537eb642131fbbcb14a485b11ce3ed4a636 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1268256 > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Auto-Submit: Robert Phillips <robertphillips@google.com> > Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> |
Robert Phillips <robertphillips@google.com> | yes | upstream | 2026-06-17 | |
| CVE-2026-17914 | Fix salt value used for expat in parsing XML We started setting the salt in [1] to avoid using the secure PRNG generator on Windows [2][3] but the choice of using a pointer was undesirable (see linked bug). This uses SkRandom and the time to avoid leaking info while using a hard-to-guess salt to mitigate the original hash-flooding DOS attack without causing additional problems. SkRandom is portable and doesn't use any external sources of entropy, avoiding the original problem. [1] https://review.skia.org/730076 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-06-23 | |
| CVE-2026-17992-a | Handle w<=0 conics SkPath had special logic for degenerate conics [1] and SkGeometry has an assumption of positive weights [2][3] (possibly other places too), so this restores that logic to turn it into a lineTo. [1] https://github.com/google/skia/blob/19936eb1b23fef5187b07fb2e0e67dcf605c0672/src/core/SkPath.cpp#L754-L756 [2] https://github.com/google/skia/blob/d7196b0b493925df3be1e259f41a3c6678732b45/src/core/SkGeometry.h#L350 [3] https://review.skia.org/667436 [4] https://review.skia.org/1225597 |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-06-16 | |
| CVE-2026-17992-b | Add error handling and initialization to the DWFM Within SkScalerContext_DW::generateFontMetrics(), the `dwfm` variable does not get initialized, and if GetGDICompatibleMetrics() fails, then it could remain uninitialized. This CL null initializes dwfm and checks the return value of GetGdiCompatibleMetrics. |
Alexis Cruz-Ayala <alexisdavidc@google.com> | yes | upstream | 2026-06-17 | |
| CVE-2026-19154 | [ganesh][gl] Imagination FBO deletion workaround * Adds workaround for driver level bug where a context retains a reference to a deleted FBO, resulting in a UAF hazard. |
Thomas Smith <thomsmit@google.com> | yes | upstream | 2026-07-20 | |
| CVE-2026-19160 | [ganesh] Check results of internal flushes for internalWritePixels success This moves the caps' dependent pre-flush out of newWritePixelsTask and performs the flush inside internalWritePixels. Also checks for the success of the flush at the end of internalWritePixels when the source pixel data isn't owned. These use a shared helper function. Adds a unit test that can trigger writing stale scratch texture contents if the internalWritePixels' flush failed when performing an upload to the scratch texture when taking a write-as-draw path for the primary writePixels target. |
Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-07-23 | |
| CVE-2026-19161 | [ganesh] Skip resolve/mipmap step on flush failure This AI generated patch seems reasonable and harmless enough. I do think that it is only a small part of a larger problem around Ganesh's handling of flush failures. In practice, Chrome will have to have handled the flush failure via the callback system in order to respond to the failure. That handling should discard the texture the bug is worried about. This CL adds a bit of defense in depth (and seems harmless). |
Robert Phillips <robertphillips@google.com> | yes | upstream | 2026-07-22 | |
| CVE-2026-19176 | Address incorrect handling of a map pointer in SkRP In pushChildCall, we held on to a pointer from a fChildEffectMap and then later dereferenced it. However, in between those points was a code path that could grow the map, invalidating the pointer. This is demonstrated in the newly added test. To fix it, we just dereference it earlier. While tracking this down, I found a suspicious other usage of the map which works in newer C++, but could break in older versions. It's trivial to fix Generator::writeFunction, so I handled that as well. |
Kaylee Lubick <kjlubick@google.com> | yes | upstream | 2026-07-29 | |
| CVE-2026-76041 | [ganesh] Check result inside GrResourceProvider::writePixels | Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-08-04 | |
| CVE-2026-79144 | [Security] Add a SmallPathIDChangeListener to SmallPathAtlasMgr There was a vulnerability where SkPathID could have duplicate entries if an attacker created and discarded enough Small, Complex Paths to overwhelm the SmallPathAtlasMgr cache. This could lead to the attacker submitting a request to the cache for a path, and receiving a victim's path instead. The solution involved mirroring what is done in the SoftwarePathRenderer.cpp and using an SkIDChangeListener to listen for when a path is modified or discarded and delete the entry in the cache. This way, duplicate entries are avoided. A test was added that shows that an ID collision can be forced amongst SmallPaths with complex geometry; any hash of two small, complex paths would rely only on the genID, making it easier to hit a duplicate entry. |
Alexis Cruz-Ayala <alexisdavidc@google.com> | yes | upstream | 2026-07-17 | |
| CVE-2026-84359 | [graphite] Track resources before adding barriers to VulkanCommandBuffer | Michael Ludwig <michaelludwig@google.com> | yes | upstream | 2026-06-16 | |
| CVE-2026-85049 | Fix UAF in SkCachedData::internalUnref Destroy AutoMutexWritable before calling delete this in SkCachedData::internalUnref to avoid unlocking the mutex after the object has been deleted. This was found while trying to enable the MiraclePtr rewrite that would protect "this" and cause deterministic termination. |
Arthur Sonzogni <arthursonzogni@chromium.org> | yes | upstream | 2026-08-27 |