Date: 17 Jun 2004 20:26:47 +0200
From: SecuriTeam <support@securiteam.com>
To: list@securiteam.com
Subject: [UNIX] Linux Kernel i2c Integer Overflow Vulnerability
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Linux Kernel i2c Integer Overflow Vulnerability
------------------------------------------------------------------------
SUMMARY
The Linux Kernel is the core of the Linux Operating System, and provides
the usual features of a modern multi-user kernel. Drivers to support many
different devices are available packaged with the Linux Kernel, including
the 'i2c' driver, which provides support for the 2-wire I2C bus.
In the i2c driver, there is integer overflow vulnerability during the
allocation of memory, potentially opening any systems using the i2c driver
up to a security hole.
DETAILS
Vulnerable Systems:
* Linux Kernel version 2.4.x
The integer overflow problem becomes present when allocating memory, which
is allowed to occur because of a lack of sanity checks. Below is the
vulnerable code, which is part of the i2cproc_bus_read() routine, in the
i2c-core.c component of the driver:
ssize_t i2cproc_bus_read(struct file * file, char *
buf,size_t count,
loff_t *ppos)
{
struct inode * inode =
file->f_dentry->d_inode;
char *kbuf;
struct i2c_client *client;
int i,j,k,order_nr,len=0;
size_t len_total;
int order[I2C_CLIENT_MAX];
if (count > 4000)
return -EINVAL;
len_total = file->f_pos + count;
/* Too bad if this gets longer (unlikely) */
if (len_total > 4000)
len_total = 4000;
for (i = 0; i < I2C_ADAP_MAX; i++)
if (adapters[i]->inode ==
inode->i_ino) {
/* We need a bit of slack in the
kernel buffer; this makes the
sprintf safe. */
if (! (kbuf = kmalloc(count +
80,GFP_KERNEL)))
return -ENOMEM;
[...]
Although a quick check is made to ensure that the user-supplied variable
'count' does not exceed 4000, sanity checks do not occur to check for
negative integers in the 'count' variable. Since negative integers simply
become _very_ large integers when represented as unsigned, a negative
count argument to kmalloc() would cause unexpected behavior. The call
looks like this:
if (! (kbuf = kmalloc(count + 80,GFP_KERNEL)))
For example, if '-1' was passed to the routine as the 'count' argument,
the above kmalloc() call would be equivalent to below:
if (! (kbuf = kmalloc(0xffffffff + 80,GFP_KERNEL)))
This would cause an integer overflow during the kmalloc() call when 80 is
added to count, resulting in a very small amount of memory being
allocated. As in the comment just above the vulnerable kmalloc() call (/*
We need a bit of slack in the kernel buffer; this makes the sprintf safe.
*/), the purpose of incrementing the 'count' argument by 80 is to stop the
chance of a buffer overflow, but by supplying a suitable negative integer
as 'count' (i.e. -1), this allows an integer overflow, causing the
kmalloc() argument to wrap back round to a small/negative value.
In the sprintf() calls following the kmalloc() call, there is quite a
possibility of overflowing the bounds of the newly allocated very small
chunk of memory. This might result in kernel panic, corruption of kernel
memory, or maybe even elevation of privileges, however unlikely.
i2cproc_bus_read() is implemented as a read() hook in the driver, as
below:
static struct file_operations i2cproc_operations = {
read: i2cproc_bus_read,
};
This might allow unprivileged users to exploit the issue. Please take note
that this potential security hole only affects those using the i2c driver
-- if this driver (it can be installed as either a module or built into
the kernel) is not installed on your system, you're not vulnerable.
Workaround
The following sanity check can be added to the beginning of the
i2cproc_bus_read() in the i2c-core.c file:
if(count < 0)
return -EINVAL;
A simpler alternative workaround is to disable the module if possible, or
remove the driver if it's not needed by the system.
ADDITIONAL INFORMATION
The information has been provided by <mailto:shaunige@yahoo.co.uk> Shaun
Colley.
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
