linux-kernel - tty: closing n_gsm line discipline always times out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170517134456.hx2dp6zszv6wyr6y@pengutronix.de>
Date:   Wed, 17 May 2017 15:44:56 +0200
From:   Sascha Hauer <s.hauer@...gutronix.de>
To:     linux-kernel@...r.kernel.org
Cc:     kernel@...gutronix.de,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>
Subject: tty: closing n_gsm line discipline always times out

Hi All,

When the n_gsm line discipline is closed it wants to shutdown the line
discipline properly and asks the link partner to end the mux protocol. This is
done in gsm_cleanup_mux() around line 2050 in n_gsm.c:

	if (dlci) {
		gc = gsm_control_send(gsm, CMD_CLD, NULL, 0);
		if (gc)
			gsm_control_wait(gsm, gc);
	}

The call stack is like this:

(struct tty_ldisc_ops).close
  -> gsmld_close
    -> gsmld_detach_gsm
      -> gsm_cleanup_mux

(struct tty_ldisc_ops).close is called at tty_release time or when the line
discipline is changed.  At tty_release time the tty is already shutdown, so we
cannot send anything anymore. In this case our link partner never closes the
mux protocol, which means we can never re-open it again.  When instead the line
discipline is changed back to N_TTY to close the protocol, gsm_control_send
works fine, but the tty_ldisc is locked and thus the chars received by the UART
never make it to the line discipline and gsm_control_wait times out.

There's obviously something wrong here. Any ideas how to fix that? When we are
not allowed to send/receive at tty_release time, do we need a new n_gsm specific
ioctl to shutdown the mux?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |