Re: [PATCH] TTY: serial, stop accessing potential NULLs

[David Miller]

From: Jiri Slaby <jslaby@xxxxxxx>
Date: Thu, 14 Mar 2013 00:30:34 +0100

> The following commits:
> * 6732c8bb8671acbdac6cdc93dd72ddd581dd5e25 (TTY: switch
>   tty_schedule_flip)
> * 2e124b4a390ca85325fae75764bef92f0547fa25 (TTY: switch
>   tty_flip_buffer_push)
> * 05c7cd39907184328f48d3e7899f9cdd653ad336 (TTY: switch
>   tty_insert_flip_string)
> * 92a19f9cec9a80ad93c06e115822deb729e2c6ad (TTY: switch
>   tty_insert_flip_char)
> * 227434f8986c3827a1faedd1feb437acd6285315 (TTY: switch
>   tty_buffer_request_room to tty_port)
> 
> introduced a potential NULL dereference to some drivers. In
> particular, when the device is used as a console, incoming bytes can
> kill the box. This is caused by removed checks for TTY against NULL.
> 
> It happened because it was unclear to me why the checks were there. I
> assumed them superfluous because the interrupts were unbound or
> otherwise stopped. But this is not the case for consoles for these
> drivers, as was pointed out by David Miller.
> 
> Now, this patch re-introduces the checks (at this point we check
> port->state, not the tty proper, as we do not care about tty pointers
> anymore). For both of the drivers, we place the check below the
> handling of break signal so that sysrq can actually work. (One needs
> to issue a break and then sysrq key within the following 5 seconds.)
> 
> We do not change sc26xx, sunhv, and sunsu here because they behave the
> same as before.  People having that hardware should fix the driver
> eventually, however. They always could unconditionally dereference tty
> in receive_chars, port->state in uart_handle_dcd_change, and
> up->port.state->port.tty.
> 
> There is perhaps more to fix in all those drivers, but they are at
> least in a state they were before.
> 
> Signed-off-by: Jiri Slaby <jslaby@xxxxxxx>

Acked-by: David S. Miller <davem@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/