Fix use-after-free when a CanvasPattern outlives its source Image

[iurisilvio]

Use-after-free: a CanvasPattern built from an Image can outlive the pixel buffer it points at

Reopening — this was closed as unnecessary, but the case below is a genuine use-after-free, not just defensive retention.

Root cause

Pattern::Pattern builds its cairo pattern from the source surface:

_pattern = cairo_pattern_create_for_surface(surface);   // src/CanvasPattern.cc

For images decoded from JPEG/GIF/raw data, that surface is created with cairo_image_surface_create_for_data(_data, …) — the pixel buffer _data is owned by the Image, not by cairo. When the source Image is GC'd, Image::clearData() runs:

void Image::clearData() {
  if (_surface) { cairo_surface_destroy(_surface); … }
  delete[] _data;     // unconditional — even if a pattern still references the surface
  _data = nullptr;
}

cairo_pattern_create_for_surface references the surface object (so cairo_surface_destroy doesn't free the struct), but nothing keeps _data alive and clearData() frees it unconditionally. Any later use of the pattern reads freed memory.

Repro (node --expose-gc repro.js)

const { createCanvas, loadImage } = require('canvas')
;(async () => {
  const src = createCanvas(128, 128); src.getContext('2d').fillRect(0, 0, 128, 128)
  const jpeg = src.toBuffer('image/jpeg')        // decodes via create_for_data

  const out = createCanvas(256, 256)
  const ctx = out.getContext('2d')
  let pattern
  {
    const img = await loadImage(jpeg)
    pattern = ctx.createPattern(img, 'repeat')   // pattern references img's surface
  }                                              // no JS ref to img survives
  for (let i = 0; i < 10; i++) global.gc()       // ~Image -> clearData() -> delete[] _data

  ctx.fillStyle = pattern
  ctx.fillRect(0, 0, 256, 256)                   // reads freed _data
  out.toBuffer('image/png')                      // UAF
})()

An ASan build reports heap-use-after-free in cairo while reading the surface data; a release build produces garbled output or crashes intermittently.

Re: "the cairo pattern already holds a reference, so this is unnecessary"

True for surfaces cairo owns — Canvas surfaces and PNGs via create_from_png, whose data cairo keeps alive by refcount. It is not true for create_for_data surfaces (JPEG/GIF/raw), where the buffer lifetime is tied to the Image and freed in clearData(). The persistent reference is what bridges that gap; cairo's refcount does not cover the externally-owned buffer.

Fix

Hold a strong reference to the source Image/Canvas for the pattern's lifetime, so its backing buffer stays alive as long as the pattern can be used. Verified: with the reference held the pattern survives GC of its source Image; without it the repro above faults.

[iurisilvio]

Closing: this is a real use-after-free by code analysis (Image::clearData() frees the create_for_data pixel buffer unconditionally while a CanvasPattern still references the surface), but I could not reproduce it as observable corruption or a crash in a normal build — the freed buffer isn't reused by JS-side allocations, so demonstrating it would need an ASan build. Scoping to fixes reproduced with before/after measurements.