TIOCSTI, infamously the subject of reports like CVE-2013-6409, CVE-2015-6565, CVE-2016-2779, CVE-2016-7545, and CVE-2017-5226, is a mechanism in operating system kernels.
The fact that it is a problem is old news, as you can see in some of the year numbers of the aforementioned, and the reason that it keeps being re-reported afresh is that people keep pointing to the wrong locus of the problem.
Anecdotally, when this came up on Hacker News, one person reported having experienced the problems with this back in 1985; it is that old a known problem.
Ron Stanonik knew that it was a security hole in 1992, and the true solution to that problem was of course to eval the output of tset -s, no terminal shenanighans required, as Jim Cottrell, Brandon S. Allbery, and others knew in 1988.
Even Chris Siebennmann was in the know about this in 1991, there being a discussion about its insecurity involving Daniel J. Bernstein, whose PTY tools had been celebrated in comp.sources.unix the year before.
If you've heard of Jakub Wilk's ttyjack and been scared by it in 2017, note that Daniel J. Bernstein wrote ttyctrl in 1989 and set off a Usenet flame war.
This is an old insecurity; and people used to be clueful enough to know where its locus is. Unfortunately, 30 years later people are blaming all sorts of things, instead of doing what those Usenet posters reported commercial Unices doing in the 1990s.
Assertions that it is a bug in sudo are false.
Assertions that it is a bug in su are false.
Assertions that it is a bug in doas are false.
Assertions that it is a bug in OpenDOAS are false.
It is not in the code of any of those programs.
It is not a function of any of those programs.
It pre-dates the very existences of three of them.
It is in the code of operating system kernels; it is problematic functionality provided by operating system kernels; and it is fixed by fixing those operating system kernels.
Back in the time of those Usenet discussions, you can see participants mentioning that the (BSD-based) Unices were hedging it with restrictions on its operation, and that AT&T Unix System 5 simply didn't have the mechanism in the first place.
The TIOCSTI mechanism was added to Linux by Linus Torvalds on 1993-12-23.
Pete French added it to FreeBSD against his better judgement on 2010-01-04.
It might have been in an earlier implementation of the terminal line discipline, too.
It did exist historically in BSD and SunOS.
OpenBSD had had it since the initial import from NetBSD in 1995.
Illumos has it, and has had since at least the OpenSolaris launch.
There are three known uses of it.
Theo de Raadt reported, as did Milosav Trmac long before, that it was historically used in the line editor of the C shell and in the line editor of the BSD Mail program when editing message headers.
However, the existences of GNU Readline, libedit, ZLE, and other line editors that manage to get by without using it at all tells one that it is clearly not a necessary component of a line editor.
Those line editors in the C shell and Mail were old, and their later alternatives do not re-inject characters into the terminal input stream to get their jobs done.
(The C shell used the line discipline's editor, and this was its way of pushing filename completions back into the line discipline's input stream.
Modern line editors operate the line discipline in non-canonical mode, and simply handle everything, including all of the special characters that some modern guides to Unices and Linux-based operating systems still erroneously say are handled by the line discpline.
Terminal line disciplines are rarely in canonical mode any more.
When the shell hasn't set non-canonical mode, a program with a full-screen TUI such as a pager or a text editor or a program with a line editor such as GDB, often has.)
The one remaining reported use is by BRLTTY, a Braille I/O utility for partly-sighted and blind people. This uses it to inject input generated by the Braille terminal into the operating system's terminal device.
I laid out an alternative way for BRLTTY to work back in 2014. It uses no special kernel mechanisms, only pseudo-terminals, FIFOs, and regular files. For the people complaining about BRLTTY being potentially broken in 2023, there had actually been a solution, and the terminal end written, packaged, and published, for 9 years at that point.
Since even BRLTTY can be fixed, TIOCSTI is of no Earthly use.
OpenBSD people made using it simply an error in 2017, fixing the mail utility (as it is now named) along the way.
The same was proposed in Linux in 2017, but as reported it was rejected over and over and over and over and over and over and over and over and over.
Linux developer Alan Cox expressed the view that, in addition to all of the PAM stuff that programs like (util-linux) su, sudo, and OpenDOAS had to do in a retained parent process, that parent process should also be managing a pseudo-terminal, handling passing signals to the child, handling job suspension notifications from the child, keeping the getlogname() result consistent, and pumping character I/O.
They would be well on the way to becoming screen with a PAM front-end, or at least Bernstein ptybandage.
It was not until years later, in 2022, that patches made it past this "No" Barrier and Linux gained the ability to at least optionally get rid of TIOCSTI.