<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/tty, branch v4.15.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>serial: core: mark port as initialized after successful IRQ change</title>
<updated>2018-02-07T19:14:14+00:00</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2018-01-11T17:57:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b796d30928fe3f80e8f02400573e7e31df2fc8b8'/>
<id>b796d30928fe3f80e8f02400573e7e31df2fc8b8</id>
<content type='text'>
commit 44117a1d1732c513875d5a163f10d9adbe866c08 upstream.

setserial changes the IRQ via uart_set_info(). It invokes
uart_shutdown() which free the current used IRQ and clear
TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke
uart_startup() before returning to the caller leaving
TTY_PORT_INITIALIZED cleared.

The next open will crash with
|  list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98.
since the close from the IOCTL won't free the IRQ (and clean the list)
due to the TTY_PORT_INITIALIZED check in uart_shutdown().

There is same pattern in uart_do_autoconfig() and I *think* it also
needs to set TTY_PORT_INITIALIZED there.
Is there a reason why uart_startup() does not set the flag by itself
after the IRQ has been acquired (since it is cleared in uart_shutdown)?

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 44117a1d1732c513875d5a163f10d9adbe866c08 upstream.

setserial changes the IRQ via uart_set_info(). It invokes
uart_shutdown() which free the current used IRQ and clear
TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke
uart_startup() before returning to the caller leaving
TTY_PORT_INITIALIZED cleared.

The next open will crash with
|  list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98.
since the close from the IOCTL won't free the IRQ (and clean the list)
due to the TTY_PORT_INITIALIZED check in uart_shutdown().

There is same pattern in uart_do_autoconfig() and I *think* it also
needs to set TTY_PORT_INITIALIZED there.
Is there a reason why uart_startup() does not set the flag by itself
after the IRQ has been acquired (since it is cleared in uart_shutdown)?

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS</title>
<updated>2018-02-03T16:58:42+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@nxp.com</email>
</author>
<published>2018-01-04T17:58:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=68c610bf1e38e3a01a17bd101b089102a76d03b3'/>
<id>68c610bf1e38e3a01a17bd101b089102a76d03b3</id>
<content type='text'>
commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream.

The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.

Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD")
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Reviewed-by: Martin Kaiser &lt;martin@kaiser.cx&gt;
Acked-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream.

The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.

Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD")
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Reviewed-by: Martin Kaiser &lt;martin@kaiser.cx&gt;
Acked-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_dw: Revert "Improve clock rate setting"</title>
<updated>2018-02-03T16:58:42+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2018-01-19T16:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=150becd9a389d04fd73a0f7feffbcba4d88aa11b'/>
<id>150becd9a389d04fd73a0f7feffbcba4d88aa11b</id>
<content type='text'>
commit c14b65feac9ebed649d6fe79c6b6d64d21d0287d upstream.

The commit

  de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")

obviously tries to cure symptoms, and not a root cause.

The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.

Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.

Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].

Taking above, revert the commit de9e33bdfa22 for now.

[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782

Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
Cc: Ed Blake &lt;ed.blake@sondrel.com&gt;
Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Cc: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c14b65feac9ebed649d6fe79c6b6d64d21d0287d upstream.

The commit

  de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")

obviously tries to cure symptoms, and not a root cause.

The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.

Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.

Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].

Taking above, revert the commit de9e33bdfa22 for now.

[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782

Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
Cc: Ed Blake &lt;ed.blake@sondrel.com&gt;
Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Cc: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_uniphier: fix error return code in uniphier_uart_probe()</title>
<updated>2018-02-03T16:58:41+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>weiyongjun1@huawei.com</email>
</author>
<published>2018-01-04T07:42:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c0dbcbb52e8ccc4044d9c42cbe4bc56e82121bfd'/>
<id>c0dbcbb52e8ccc4044d9c42cbe4bc56e82121bfd</id>
<content type='text'>
commit 7defa77d2baca4d6eb85234f10f38ab618332e75 upstream.

Fix to return a negative error code from the port register error
handling case instead of 0, as done elsewhere in this function.

Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data")
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Acked-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7defa77d2baca4d6eb85234f10f38ab618332e75 upstream.

Fix to return a negative error code from the port register error
handling case instead of 0, as done elsewhere in this function.

Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data")
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Acked-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_of: fix return code when probe function fails to get reset</title>
<updated>2018-02-03T16:58:41+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2017-12-27T05:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=970aeba3f3e5d46352244c997d33800eeb0fcb4a'/>
<id>970aeba3f3e5d46352244c997d33800eeb0fcb4a</id>
<content type='text'>
commit b9820a31691b771db37afe2054dd3d3a680c1eed upstream.

The error pointer from devm_reset_control_get_optional_shared() is
not propagated.

One of the most common problem scenarios is it returns -EPROBE_DEFER
when the reset controller has not probed yet.  In this case, the
probe of the reset consumer should be deferred.

Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support")
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b9820a31691b771db37afe2054dd3d3a680c1eed upstream.

The error pointer from devm_reset_control_get_optional_shared() is
not propagated.

One of the most common problem scenarios is it returns -EPROBE_DEFER
when the reset controller has not probed yet.  In this case, the
probe of the reset consumer should be deferred.

Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support")
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty: fix data race between tty_init_dev and flush of buf</title>
<updated>2018-02-03T16:58:37+00:00</updated>
<author>
<name>Gaurav Kohli</name>
<email>gkohli@codeaurora.org</email>
</author>
<published>2018-01-23T07:46:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e1995ed770e780b423b31b160570bff2d4769d3'/>
<id>3e1995ed770e780b423b31b160570bff2d4769d3</id>
<content type='text'>
commit b027e2298bd588d6fa36ed2eda97447fb3eac078 upstream.

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty-&gt;disc_data
may be NULL.

CPU0					CPU1
----					----
 000|n_tty_receive_buf_common()   	n_tty_open()
-001|n_tty_receive_buf2()		tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline)	tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli &lt;gkohli@codeaurora.org&gt;
Reviewed-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b027e2298bd588d6fa36ed2eda97447fb3eac078 upstream.

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty-&gt;disc_data
may be NULL.

CPU0					CPU1
----					----
 000|n_tty_receive_buf_common()   	n_tty_open()
-001|n_tty_receive_buf2()		tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline)	tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli &lt;gkohli@codeaurora.org&gt;
Reviewed-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)</title>
<updated>2017-12-21T10:19:22+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-12-21T01:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=966031f340185eddd05affcf72b740549f056348'/>
<id>966031f340185eddd05affcf72b740549f056348</id>
<content type='text'>
We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serdev: ttyport: fix tty locking in close</title>
<updated>2017-11-28T15:00:50+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-11-03T14:30:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=90dbad8cd6efccbdce109d5ef0724f8434a6cdde'/>
<id>90dbad8cd6efccbdce109d5ef0724f8434a6cdde</id>
<content type='text'>
Make sure to hold the tty lock as required when calling tty-driver
close() (e.g. to avoid racing with hangup()).

Note that the serport active flag is currently set under the lock at
controller open, but really isn't protected by it.

Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make sure to hold the tty lock as required when calling tty-driver
close() (e.g. to avoid racing with hangup()).

Note that the serport active flag is currently set under the lock at
controller open, but really isn't protected by it.

Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serdev: ttyport: fix NULL-deref on hangup</title>
<updated>2017-11-28T15:00:50+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-11-03T14:30:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8bcd4e6a8decac251d55c4377e2e67f052777ce0'/>
<id>8bcd4e6a8decac251d55c4377e2e67f052777ce0</id>
<content type='text'>
Make sure to use a properly refcounted tty_struct in write_wake up to
avoid dereferencing a NULL-pointer when a port is being hung up.

Fixes: bed35c6dfa6a ("serdev: add a tty port controller driver")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 4.11
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make sure to use a properly refcounted tty_struct in write_wake up to
avoid dereferencing a NULL-pointer when a port is being hung up.

Fixes: bed35c6dfa6a ("serdev: add a tty port controller driver")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 4.11
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serdev: ttyport: add missing receive_buf sanity checks</title>
<updated>2017-11-28T15:00:50+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-11-03T14:30:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eb281683621b71ab9710d9dccbbef0c2e1769c97'/>
<id>eb281683621b71ab9710d9dccbbef0c2e1769c97</id>
<content type='text'>
The receive_buf tty-port callback should return the number of bytes
accepted and must specifically never return a negative errno (or a value
larger than the buffer size) to the tty layer.

A serdev driver not providing a receive_buf callback would currently
cause the flush_to_ldisc() worker to spin in a tight loop when the tty
buffer pointers are incremented with -EINVAL (-22) after data has been
received.

A serdev driver occasionally returning a negative errno (or a too large
byte count) could cause information leaks or crashes when accessing
memory outside the tty buffers in consecutive callbacks.

Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Cc: stable &lt;stable@vger.kernel.org&gt;	# 4.11
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The receive_buf tty-port callback should return the number of bytes
accepted and must specifically never return a negative errno (or a value
larger than the buffer size) to the tty layer.

A serdev driver not providing a receive_buf callback would currently
cause the flush_to_ldisc() worker to spin in a tight loop when the tty
buffer pointers are incremented with -EINVAL (-22) after data has been
received.

A serdev driver occasionally returning a negative errno (or a too large
byte count) could cause information leaks or crashes when accessing
memory outside the tty buffers in consecutive callbacks.

Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Cc: stable &lt;stable@vger.kernel.org&gt;	# 4.11
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
