Passphrases over ~64 bytes can't unlock keys with kernel 5.11.3/5.10.20
Issue description
Since kernel 5.12-rc2, 5.11.3, 5.10.20 (and others), cryptsetup cannot unlock keyslots whose password is somewhere over the 64 byte mark.
The untimed_read() function in src/utils_password.c reads the passphrase with a single call to read(), which would not work in the event the passphrase is split by the kernel, requiring multiple read() calls.
Enter the following change to TTY I/O in the aforementioned kernels: tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer --- drivers/tty/tty_io.c
To accomodate further commits adding read_iter() and support for .splice_read(), instead of calling ld->ops->read() with the user (i.e. cryptsetup) buffer and size, the new tty_io.c code reads up to 64 bytes of the TTY data into a private kernel buffer of that size, and copies that to the user (cryptsetup) buffer.
Now, at first glance at the kernel code (and documentation) it would appear that the code does so iteratively, until there is data available and the user buffer is filled, so long as the TTY driver sets a cookie to non-NULL. However, a further review of the whole commit shows that all but one (the one for TTY drivers using HDLC line displine) of the TTY read() implementations DO NOT set such cookie. As a result, read() would now only produce 64 bytes of the passphrase for cryptsetup to use, and passwords longer than this no longer work.
Steps for reproducing the issue
Add a key slot with a passphrase of more than 64 bytes in it, switch to kernel 5.11.3, and try to unlock crypto volume from virtual console?