diff options
author | Dan Rosenberg <drosenberg@vsecurity.com> | 2011-07-12 01:08:23 +0400 |
---|---|---|
committer | James Bottomley <JBottomley@Parallels.com> | 2011-07-27 17:26:21 +0400 |
commit | b5b515445f4f5a905c5dd27e6e682868ccd6c09d (patch) | |
tree | eeec9b3c3cf70581aeae1a281f40a32611218e63 /ipc | |
parent | 5911e963d3718e306bcac387b83e259aa4228896 (diff) | |
download | linux-b5b515445f4f5a905c5dd27e6e682868ccd6c09d.tar.xz |
[SCSI] pmcraid: reject negative request size
There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.
First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL. This calls through to
pmcraid_ioctl_passthrough(). Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user. If a negative value is provided
here, bad things can happen. For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.
It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions