diff options
| author | Jonathan Salwan <jonathan.salwan@gmail.com> | 2013-07-03 15:01:13 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2013-07-03 16:07:25 -0700 |
| commit | 542db01579fbb7ea7d1f7bb9ddcef1559df660b2 (patch) | |
| tree | 2f799eec82446074973943524f19d116a9414392 | |
| parent | 8b0d77f13192678019f07cbc6b3338d6d91f1cf4 (diff) | |
| download | linux-542db01579fbb7ea7d1f7bb9ddcef1559df660b2.tar.gz linux-542db01579fbb7ea7d1f7bb9ddcef1559df660b2.tar.bz2 linux-542db01579fbb7ea7d1f7bb9ddcef1559df660b2.zip | |
drivers/cdrom/cdrom.c: use kzalloc() for failing hardware
In drivers/cdrom/cdrom.c mmc_ioctl_cdrom_read_data() allocates a memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy_to_user function:
2908 if (!ret && copy_to_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this function.
If ret = 0 with the previous basic block, it's possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| -rw-r--r-- | drivers/cdrom/cdrom.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index d620b4495745..8a3aff724d98 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -2882,7 +2882,7 @@ static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi, if (lba < 0) return -EINVAL; - cgc->buffer = kmalloc(blocksize, GFP_KERNEL); + cgc->buffer = kzalloc(blocksize, GFP_KERNEL); if (cgc->buffer == NULL) return -ENOMEM; |