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]
Date:	Tue, 9 Dec 2014 11:52:05 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: potential corruption in synclink driver

Hi Jiri, I hate to bother you with this, but you're the TTY expert.  I'm
getting the following static checker warning:

	drivers/tty/synclink.c:4057 save_tx_buffer_request()
	error: 'BufferSize' from user is not capped properly

drivers/tty/synclink.c
  4047  static int save_tx_buffer_request(struct mgsl_struct *info,const char *Buffer, unsigned int BufferSize)
  4048  {
  4049          struct tx_holding_buffer *ptx;
  4050  
  4051          if ( info->tx_holding_count >= info->num_tx_holding_buffers ) {
  4052                  return 0;               /* all buffers in use */
  4053          }
  4054  
  4055          ptx = &info->tx_holding_buffers[info->put_tx_holding_index];
  4056          ptx->buffer_size = BufferSize;
  4057          memcpy( ptx->buffer, Buffer, BufferSize);
                                             ^^^^^^^^^^
  4058  
  4059          ++info->tx_holding_count;
  4060          if ( ++info->put_tx_holding_index >= info->num_tx_holding_buffers)
  4061                  info->put_tx_holding_index=0;
  4062  
  4063          return 1;
  4064  }

ptx->buffer is allocated in mgsl_alloc_intermediate_txbuffer_memory()
and it can be up to "info->max_frame_size" bytes which is a number
between 4096 and 65535.

The way I read it, BufferSize comes from do_tty_write() and it could be
up to 65536.  That's obviously one higher than 65535.  But if
->max_frame_size is 4096 then that's a lot higher.

This looks like a potential buffer overflow but I don't know the TTY
layer enough to be sure.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ