On Fri, Feb 08, 2019 at 04:06:09PM -0700, Shuah Khan wrote:
tty_set_termios() has the following WARN_ON which can be triggered with a
syscall to invoke TIOCSETD __NR_ioctl.
WARN_ON(tty->driver->type == TTY_DRIVER_TYPE_PTY &&
tty->driver->subtype == PTY_TYPE_MASTER);
Reference: https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
"The problem started with commit 7721383f4199 ("Bluetooth: hci_uart: Support
operational speed during setup") which introduced a new way for how
tty_set_termios() could end up being called for a master pty."
Fix hci_uart_tty_open() to check if tty supports set_termios in addition
to write and error out, if it doesn't.
Reported-by: syzbot+a950165cbb86bdd023a4@xxxxxxxxxxxxxxxxxxxxxxxxx
Cc: Johan Hovold <johan@xxxxxxxxxx>
Cc: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Shuah Khan <shuah@xxxxxxxxxx>
---
drivers/bluetooth/hci_ldisc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index fbf7b4df23ab..087ec2268744 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -474,10 +474,10 @@ static int hci_uart_tty_open(struct tty_struct *tty)
BT_DBG("tty %p", tty);
- /* Error if the tty has no write op instead of leaving an exploitable
- * hole
+ /* Error if the tty has no write/set_termios ops instead of leaving
+ * an exploitable hole.
Why do you think that a tty driver not implementing set_termios() is
exploitable?
Note that tty_set_termios() handles a missing set_termios() callback
just fine without dereferencing a NULL-pointer. >
*/
- if (tty->ops->write == NULL)
+ if (!tty->ops->write || !tty->ops->set_termios)
return -EOPNOTSUPP;
I know Marcel asked you do implement things like this, but what you're
really doing is to try to uphold the invariant that tty_set_termios()
should never be called for a pty master. The WARN_ON in that function
was put in place to make sure line-disciplines use the correct ioctl
helpers (and the commit I pointed you to earlier in the paragraph you
quote in the commit message broke that invariant).
I'm afraid this is totally obscured by the above change and misleading
comment update.