Unbounded recursion between Inspect.List charlist rendering and List.to_string/1 error path in Elixir

Uncontrolled Recursion vulnerability in the Elixir standard library allows an attacker who controls a list passed to inspect/1, List.to_string/1, or List.to_charlist/1 to exhaust a BEAM node's memory.

Inspect.List's charlist branch in lib/elixir/lib/inspect.ex classifies a list as a charlist using List.ascii_printable?/2, which examines only the first :printable_limit (4096 by default) elements, and then calls IO.chardata_to_string/1 on the whole term. A list whose printable prefix exceeds that limit but which contains a later element that is not a code point (an atom, an out-of-range integer, or an improper tail) is therefore mis-classified, and the conversion raises ArgumentError. That conversion runs inside List.to_string/1, whose rescue clause builds its message by interpolating inspect(list), which re-enters the same branch and raises again. The nested inspection is an argument to raise, so the recursion is not in tail position and every level is retained: the process stack grows monotonically while each cycle re-walks the list, until the process is killed by max_heap_size or, by default, the node runs out of memory. List.to_charlist/1 has the same rescue shape.

Below the printable limit the inner inspect/1 sees the invalid element within its counter and renders the list in ordinary bracket form, so a single ArgumentError is raised and no recursion occurs.

This issue affects elixir: from 1.15.0-rc.0 before 1.18.5, from 1.19.0-rc.0 before 1.19.6, and from 1.20.0-rc.0 before 1.20.4.

Install a global inspect function that renders lists as lists rather than inferring charlists, by calling Inspect.Opts.default_inspect_fun/1 with fn term, opts -> Inspect.inspect(term, %{opts | charlists: :as_lists}) end from the application's start callback. This keeps the charlist branch from being entered at all, so the mis-inferred conversion never raises and the error path cannot recurse.

The trade-off is global: charlists then render in bracket form, so ~c"abc" inspects as [97, 98, 99] everywhere in the application, including in logs and error reports.