Colord: Slow rejection of oversized malformed color strings

Impact

colord's CSS color string matchers described a number as ([+-]?\d*\.?\d+). In that form \d* and \d+ can match the same digits, so a run of n digits can be divided between them in O(n²) ways, and rejecting an input retries every division. Parsing is synchronous and uninterruptible, so a long malformed color string blocks the thread:

| input | time to reject | | --- | --- | | 16 KB | 224 ms | | 64 KB | 4.4 s | | 128 KB | 18.5 s |

Reachable through colord() and getFormat(), and through any method that accepts a color string — including isEqual(), mix() and contrast(). The affected matchers are parseRgbaString and parseHslaString (built in) and parseHwbaString, parseLchaString, parseCmykaString (plugins).

Growth is polynomial, not exponential — multi-kilobyte payloads are required for a noticeable stall.

Who is affected

Applications that pass attacker-controlled strings of unbounded length to colord() — for example a server validating a color taken from a request body, JSON field, or uploaded stylesheet. colord applies no length limit before matching.

Typical client-side use with short input is not meaningfully affected.

Patches

Fixed in 2.9.4. The number is now written as ([+-]?(?:\d*\.\d+|\d+)), which accepts exactly the same syntax but leaves only one way to match it, making rejection linear — 1 MB of input is rejected in ~5 ms.

Workarounds

Reject or truncate color strings longer than a sane limit (e.g. 100 characters) before passing them to colord.