Bug report - CSS validator - buffer overflow because buffer is of insufficient length

Performing a CSS validation on the file https://skyeshepherdhuts.co.uk/details.css gives the crash/exception error message

    "Unknown error java.lang.RuntimeException: arraycopy: last destination index 3718 out of bounds for char[2048]"

The details.css file has on the first line an @import "common.css"; - it is within this imported file that the crash/exception is caused. It can be accessed at https://skyeshepherdhuts.co.uk/common.css.

Bugs:

1. The error message does not point out that the problem is nothing to do with any defect in the .css files. Also, there is no mention that the point where the caught exception occurs is at a certain line in _the imported .css file (common.css)_, not the main one (details.css). The text of the error ought to say that this is a fault in the CSS validator, not in the documents checked. It ought to give the line number and filename where the checker failed or where any syntax errors are found.

2. The cause of the error is a "data:" URI (there are two such instances) within common.css, which has quite a long string following it. The string is approx 3.7kB long, and it presents no problem in any modern web browser. The CSS validator does not precheck the length but just tries to copy 3.7k bytes into a 2048-byte-long buffer, and so an exception is raised to catch a crash. The 2048-bytes figure is just a meaningless arbitrary number, which will often be inadequate, and this needs to be fixed.

Fix suggestion: either increase the buffer size to, say, 64kB, but this is still an arbitrary number, so better, pre-calculate the length and allocate a buffer of at least that length if the already existing buffer is not long enough, then everywhere use a pointer to the allocated buffer in the heap or wherever it is.

Note: I don’t know what the reason is for copying the entire string. We are only syntax-checking the surrounding CSS, so why can we not just ignore the contents and skip over the string, looking for the end delimiter and checking the quoted length value (if any)? It would be extremely good to also validate the data: URI and check any length value. It can be easy to make a mess of writing a data: URI if you are not already familiar with the syntax.

3.  The tool ought to give the line number and the _filename_ where any syntax error is found. This needs to include the contents of @import files too.

4. The tool ought to tell the user whether it is also scanning the interior of an @imported file or just checking the syntax of the @import line itself and doing no more. Either is a valid choice. It would be nice to have an option tickbox to require or forbid scanning of the content of @imported files. One argument for scanning @imported files is that if the checker at some point decides to check the presence of declarations of CSS variables that are referenced somewhere, these may be standard declarations defined in an @imported file. Checking correctness of definition-use relationships wherever a reference is found.

I wasted a lot of time trying to work out why this was happening and where in the CSS the cause of the crash was because no proper error message was given. Nor was it clear to me that this crash was triggered by something in my CSS. It should never be possible to have this kind of error. More confusion is caused by the fact that the two CSS files involved were known-good, and "common.css" had not been changed, yet it turned out to be this file that was silently triggering the fault. The bug seems to have been _introduced_ in a recent version of the CSS validator because there never was such an error before and the data: URIs are not newly introduced or changed.

Best wishes,

Cecil Ward

Received on Sunday, 8 March 2026 03:27:13 UTC