Thread (25 messages) 25 messages, 3 authors, 2012-08-16

Re: [PATCH V2] [tty] Fix possible race in n_tty_read()

From: Stanislav Kozina <hidden>
Date: 2012-08-14 11:16:08

I looked a bit more at this. Excluding memory corruption which could
zero tty struct, the only possibility to nullify tty->read_buf is
call to n_tty_close(). So NULL pointer dereference on n_tty_read,
in "while (nr&&  tty->read_cnt)" loop can only be caused by calling
n_tty_close(), while performing n_tty_read().
Correct.
Stanislav patch solve that problem because we do not touch tty->read_buf
any longer once tty->read_cnt become 0, and because n_tty_close() clear
tty->read_cnt (by calling n_tty_flush_buffer() ->  reset_buffer_flags()).
Correct.
However looks like main problem persist, we should never do
n_tty_read() after/during n_tty_close() and before n_tty_open(). That
must be an issue in upper layer i.e. tty_io and tty_ldisc, which should
give guarantee about ->close(), ->read(), ->open() ordering.
Correct.
I'm going
to look at that more closely.
Thanks a lot;-)

Regards,
-Stanislav
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help