From: Jiri Slaby <jslaby@suse.cz>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: potential corruption in synclink driver
Date: Fri, 27 Feb 2015 17:07:43 +0100 [thread overview]
Message-ID: <54F0964F.6060503@suse.cz> (raw)
In-Reply-To: <20141209085205.GA28655@mwanda>
On 12/09/2014, 09:52 AM, Dan Carpenter wrote:
> 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.
Yes and no :). In theory, the only line discipline which can handle
large chunks is hdlc. That one limits the count to 4096 by default. But
you are right, if someone sets maxframe in hdlc to the maximum value
(65535) and won't set maxframe of synclinc, they will have a buffer
overflow.
These two guys are so old and ugly, maybe unused, so that I don't even
know if they are worth fixing. In the normal case (no maxframe override
on commandline/module param), they should be safe.
Maybe we can drop the support to override by parameters...
thanks,
--
js
suse labs
next prev parent reply other threads:[~2015-02-27 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 8:52 potential corruption in synclink driver Dan Carpenter
2015-02-27 16:07 ` Jiri Slaby [this message]
2015-03-02 13:22 ` One Thousand Gnomes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F0964F.6060503@suse.cz \
--to=jslaby@suse.cz \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox