@@ -76,6 +76,11 @@ static void usb_debug_process_read_urb(struct urb *urb)
usb_serial_generic_process_read_urb(urb);
}
+static void usb_debug_init_termios(struct tty_struct *tty)
+{
+ tty->termios.c_lflag &= ~ECHO;
+}
+
static struct usb_serial_driver debug_device = {
.driver = {
.owner = THIS_MODULE,
@@ -86,6 +91,7 @@ static struct usb_serial_driver debug_device = {
.bulk_out_size = USB_DEBUG_MAX_PACKET_SIZE,
.break_ctl = usb_debug_break_ctl,
.process_read_urb = usb_debug_process_read_urb,
+ .init_termios = usb_debug_init_termios,
};
static struct usb_serial_driver dbc_device = {
@@ -97,6 +103,7 @@ static struct usb_serial_driver dbc_device = {
.num_ports = 1,
.break_ctl = usb_debug_break_ctl,
.process_read_urb = usb_debug_process_read_urb,
+ .init_termios = usb_debug_init_termios,
};
static struct usb_serial_driver * const serial_drivers[] = {
This driver is intended as a "client" end of the console connection. When connected to a host it's supposed to receive debug logs, and possibly allow to interact with whatever debug console is available there. Feeding messages back, depending on a configuration may cause log messages be executed as shell commands (which can be really bad if one is unlucky, imagine a log message like "prevented running `rm -rf /home`"). In case of Xen, it exposes sysrq-like debug interface, and feeding it its own logs will pretty quickly hit 'R' for "instant reboot". Contrary to a classic serial console, the USB one cannot be configured ahead of time, as the device shows up only when target OS is up. And at the time device is opened to execute relevant ioctl, it's already too late, especially when logs start flowing shortly after device is initialized. Avoid the issue by changing default to no echo for this type of devices. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/usb/serial/usb_debug.c | 7 +++++++ 1 file changed, 7 insertions(+)