Bound numeric string length before parsing - #154689

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.

(cherry picked from commit f407f9a)

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.

(cherry picked from commit f407f9a)

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.

(cherry picked from commit f407f9a)

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.

Coercing a numeric value supplied as a string goes through new BigDecimal(String) or new BigInteger(String), whose parsing cost grows with the number of digits (super-linearly for the BigDecimal and BigInteger radix-10 constructors). The JSON parser bounds the length of an unquoted number token, but a number supplied as a quoted string is not bounded, so a single small request carrying a long digit string can consume a large amount of CPU on the thread that parses it.

This change bounds the length of a numeric string before it is parsed, using the same limit that already applies to an unquoted JSON number token. The check covers every path that coerces a user supplied numeric string to a number, including the accessors that parse via Double.parseDouble or Float.parseFloat and not only the BigDecimal/BigInteger sites, so the bound is uniform for all numeric types: the streaming parser used at index time (every integer and floating point accessor), the number and unsigned_long field mappers, and the ES|QL and SQL numeric literal and cast parsers. A value longer than the limit is rejected before the costly numeric parsing and conversion, and the limit is far above any real numeric value so valid input is unaffected.