Fix panic in feComposite arithmetic with oversized filter region

The source pixmap of a filtered group is clamped to `max_bbox` in
`render_group`, but the filter `region` in `apply_inner` was derived
directly from the unclamped filter rect. When the filter region was
larger than the clamped buffer, `feComposite` with the `arithmetic`
operator panicked on a size mismatch, since it requires its inputs and
destination to have identical dimensions:

    assertion failed: src1.height == src2.height && src1.height == dest.height

All intermediate filter images are expected to share the source's
dimensions, so clamp the region to the source bounds. This keeps every
buffer the same size and makes the affected SVG render correctly instead
of crashing (or being silently cleared).

This also fixes the `huge-region` test, whose reference image previously
captured the buggy behaviour where the filtered element disappeared; it
now renders the blurred shape correctly.

Fixes #1021. Fixes #1007.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: StefanoD

CHANGELOG.md

@@ -10,6 +10,9 @@ This changelog also contains important changes in dependencies.
 
 This release has an MSRV of 1.87.0 for `usvg` and `resvg` and the C API.
 
+### Fixed
+- Panic in `feComposite` with the `arithmetic` operator when the filter region is larger than the clamped layer. (#1021, #1007)
+
 ## [0.47.0] 2026-02-05
 
 This release has an MSRV of 1.87.0 for `usvg` and `resvg` and the C API.

crates/resvg/src/filter/mod.rs

@@ -365,6 +365,16 @@ fn apply_inner(
         .map(|r| r.to_int_rect())
         .ok_or(Error::InvalidRegion)?;
 
+    // The source pixmap is clamped to `max_bbox` in `render_group`, so the filter
+    // region (derived directly from the unclamped filter rect) can be larger than
+    // the buffer we actually render into. All intermediate filter images share the
+    // source's dimensions, so clamp the region to the source bounds to keep them
+    // consistent. Otherwise `feComposite` with the `arithmetic` operator, which
+    // requires equally sized inputs, would panic on a size mismatch.
+    let source_rect = IntRect::from_xywh(0, 0, source.width(), source.height())
+        .ok_or(Error::InvalidRegion)?;
+    let region = crate::geom::fit_to_rect(region, source_rect).ok_or(Error::InvalidRegion)?;
+
     let mut results: Vec<FilterResult> = Vec::new();
 
     for primitive in filter.primitives() {

crates/resvg/tests/integration/render.rs

@@ -81,6 +81,7 @@ use crate::render;
 #[test] fn filters_feComposite_invalid_operator() { assert_eq!(render("tests/filters/feComposite/invalid-operator"), 0); }
 #[test] fn filters_feComposite_operator_eq_arithmetic_and_invalid_k1_4() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-and-invalid-k1-4"), 0); }
 #[test] fn filters_feComposite_operator_eq_arithmetic_on_sRGB() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-on-sRGB"), 0); }
+#[test] fn filters_feComposite_operator_eq_arithmetic_with_huge_region() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-with-huge-region"), 0); }
 #[test] fn filters_feComposite_operator_eq_arithmetic_with_large_k1_4() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-with-large-k1-4"), 0); }
 #[test] fn filters_feComposite_operator_eq_arithmetic_with_opacity_on_sRGB() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-with-opacity-on-sRGB"), 0); }
 #[test] fn filters_feComposite_operator_eq_arithmetic_with_opacity() { assert_eq!(render("tests/filters/feComposite/operator=arithmetic-with-opacity"), 0); }