Terminating sudo process in the delay time results in broken behaviour for a bash session

[NotYourFox]

Working on Linux Mint 21.1 "Vera" Xfce. Using sudo v.1.9.9
Encountered a minor bug, where sudo starts behaving in an unusual way if I were to enter incorrect password and break the process during the delay.
After doing this, if you try running sudo again, it will hang. On Ctrl-C, it will show the password prompt, and when correct password is given, it will just terminate, due to Ctrl-C being pressed.

Reproduction:

1. Run "sudo (command)"
2. Enter incorrect password
3. Press Ctrl-C during delay
4. Run "sudo (command)" again

Temporary solution I found to the problem:
Simply restart the bash session. The sudo will behave normally.

Technical information:
sudo --version

Sudoers policy plugin version 1.9.9
Sudoers file grammar version 48
Sudoers I/O plugin version 1.9.9
Sudoers audit plugin version 1.9.9

inxi -Fxz

  Kernel: 5.15.0-56-generic x86_64 bits: 64 compiler: gcc v: 11.3.0
    Desktop: Xfce 4.16.0 Distro: Linux Mint 21.1 Vera base: Ubuntu 22.04 jammy
Machine:
  Type: Desktop Mobo: Acer model: Aspire TC-1660 v: V:1.1
    serial: <superuser required> UEFI: American Megatrends v: R01-B0
    date: 04/12/2022
CPU:
  Info: 6-core model: 11th Gen Intel Core i5-11400F bits: 64 type: MT MCP
    arch: Rocket Lake rev: 1 cache: L1: 480 KiB L2: 3 MiB L3: 12 MiB
  Speed (MHz): avg: 4138 high: 4288 min/max: 800/4400 cores: 1: 4027
    2: 4288 3: 3721 4: 4237 5: 4288 6: 4266 7: 4276 8: 4240 9: 4207 10: 3839
    11: 4284 12: 3988 bogomips: 62208
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: NVIDIA TU117 [GeForce GTX 1650] vendor: PC Partner / Sapphire
    driver: nouveau v: kernel bus-ID: 01:00.0
  Display: x11 server: X.Org v: 1.21.1.3 driver: X: loaded: modesetting
    unloaded: fbdev,vesa gpu: nouveau resolution: 1920x1080~60Hz
  OpenGL: renderer: NV167 v: 4.3 Mesa 22.0.5 direct render: Yes
Audio:
  Device-1: Intel Tiger Lake-H HD Audio vendor: Acer Incorporated ALI
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3
  Device-2: NVIDIA vendor: PC Partner / Sapphire driver: snd_hda_intel
    v: kernel bus-ID: 01:00.1
  Sound Server-1: ALSA v: k5.15.0-56-generic running: yes
  Sound Server-2: PulseAudio v: 15.99.1 running: yes
  Sound Server-3: PipeWire v: 0.3.48 running: yes
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: Acer Incorporated ALI driver: r8169 v: kernel port: 3000
    bus-ID: 03:00.0
  IF: enp3s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 476.94 GiB used: 20.27 GiB (4.3%)
  ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AA
    size: 476.94 GiB temp: 39.9 C
Partition:
  ID-1: / size: 182.28 GiB used: 20.24 GiB (11.1%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-2: /boot/efi size: 475.1 MiB used: 30.5 MiB (6.4%) fs: vfat
    dev: /dev/nvme0n1p1
Swap:
  ID-1: swap-1 type: partition size: 7.45 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p5
Sensors:
  System Temperatures: cpu: 67.0 C mobo: N/A gpu: nouveau temp: 48.0 C
  Fan Speeds (RPM): N/A
Info:
  Processes: 323 Uptime: 2h 20m Memory: 7.63 GiB used: 2.67 GiB (35.0%)
  Init: systemd runlevel: 5 Compilers: gcc: 11.3.0 Packages: 2411 Shell: Bash
  v: 5.1.16 inxi: 3.3.13

[millert]

What you describe is what would happen if sudo was unable to restore the terminal settings or, potentially, if the terminal settings were restored after bash regains control. Keyboard-generated signals like control-C and control-\ are blocked during password entry so this shouldn't be possible. I was unable to reproduce the problem myself on Ubuntu. It is possible that one of the PAM modules is modifying the signal mask and thus re-enabling control-C.