Normally, when invoking sudo with piped output, you'd expect the output to match and the shell's tty to still be usable (not insane with bad tty settings) after completion.

It also doesn't matter if sudo asks for the user's password.  The same mangled problem happens either way.

For example, from RHEL 9.6, you'd get:

$ ksh -c 'sudo cat /etc/services | head -3'
# /etc/services:
# $Id: services,v 1.49 2017/08/18 12:43:23 ovasik Exp $
#

(The example command above is completely for illustrative purposes of this bug only and does not require the user to set their login shell to ksh and invoke commands from the interactive shell in its typical use case.  Also, I could have used any sudo'd command piped to any other command.)

This is with:

ksh-1.0.6-6.el9.x86_64
sudo-1.9.5p2-10.el9_3.x86_64

However, on RHEL 10.0, you'll get:

$ ksh -c 'sudo cat /etc/services | head -3'
# /etc/services:
                # $Id: services,v 1.49 2017/08/18 12:43:23 ovasik Exp $
                                                                       #

This problem reproduces in a VM or on a bare metal installation.  However during my testing, I found the tty was only left insane when using a pseudo-tty (ssh session), but not when using a physical tty, but the misformatting happens in both cases.

This problem reproduces 100% of the time for me.

This was done repdoduced with:

ksh-1.0.10-4.el10.x86_64
sudo-1.9.15-8.p5.el10.x86_64

To illustrate the tty going insane, the user has to know how to type and submit a command with their tty insane.  The second invocation of "stty -g" is not visible but was typed.  For example:

$ stty -g
4500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ ksh -c 'sudo cat /etc/services | head -3'
[sudo] password for qbarnes: 

1. /etc/services:
                   # $Id: services,v 1.49 2017/08/18 12:43:23 ovasik Exp $
                                                                          #
                                                                           $ 
   4000:4:bf:a30:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
         $ 

As you can see, the tty settings do not match and have not been fully restored by sudo.

In trying to track down this problem, I can reproduce it on Fedora 39-42.  However, with Fedora 38, it determines which version of sudo is installed:

$ rpm -q ksh sudo
ksh-1.0.4-2.fc38.x86_64
sudo-1.9.13-1.p2.fc38.x86_64

(These are the versions from the Fedora 38 ISO Fedora-Workstation-Live-x86_64-38-1.6.iso.)

$ ksh -c 'sudo cat /etc/services | head -3'
# /etc/services:
# $Id: services,v 1.49 2017/08/18 12:43:23 ovasik Exp $
#

$ sudo dnf update -y sudo
[...]
$ rpm -q sudo
sudo-1.9.15-1.p5.fc38.x86_64

$ ksh -c 'sudo cat /etc/services | head -3'
# /etc/services:
                # $Id: services,v 1.49 2017/08/18 12:43:23 ovasik Exp $
                                                                       #

As you can see, the bug was introduced sometime between sudo-1.9.13-1.p2.fc38 and sudo-1.9.15-1.p5.fc38.

This also matches up with RHEL 9.6 vs. RHEL 10 with versions sudo-1.9.5p2-10.el9_3 and sudo-1.9.15-8.p5.el10, but is a wider spread than the two Fedora versions.

On Fedora, as a workaround, this problem does not reproduce with sudo-rs.