It did, actually: the filename can contain terminal control characters, which thanks to the change from safe_fprintf to fprintf, were printed without escaping, which allows the creator of the archive being extracted to control the terminal of the user extracting the archive.

That's

(a) not exploitable without the existence of a much higher-severity exploit -- sure you can clear the screen, but that's low impact

(b) possible to trigger on other extant paths; see https://github.com/libarchive/libarchive/issues/2107 so it seems nothing new was introduced

(c) kind of contrived to get to execute; you have to somehow fail to extract the archive but on the happy path you'll see a bunch of weirdly-named files

I think it's distinctly higher-probability that this change was just meant to build credibility for the GitHub account. The diff is a fairly trivial patch to a minor issue filed around the same time as the pull request.

Is it possible it was part of a planned or current exploit chain, some other way it could have been utilized?

Yes, i think one thing we should learn from this is that suspicious code is suspicious code, and anyone asserting that some suspicious code cannot be exploited is suspicious themselves. I don't think we should inquisition half the industry, but i do think people should be a lot more careful about saying that one small exploitable thing definitely cannot be part of a larger exploit.

It's obvious, basically no one knows what's going on in the _vast_ majority of code running out systems these days. And even if you know 99% the attackers only need to be right once

They still preferred to revert it as it looks very suspicious.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068047

https://github.com/libarchive/libarchive/pull/2101

If I read that correctly the problem is that it prints a filename that might include terminal control sequences that come from an attacker-controlled file name.

Comment in your second link:

https://github.com/libarchive/libarchive/pull/1609#issuecomm...