Hi !
Olaf and I have been tracking down a bug where the kernel died
into lvm_blk_open() during boot on pmac, and later on other PPCs
when trying to access an unconfigured LVM block device (or an
LVM minor not associated yet). This typically happened in the
pmac root discovery code which walks all gendisks, but I beleive
there are other possible exploits.
Here's what I've tracked down so far:
static int lvm_blk_open(struct inode *inode, struct file *file)
{
int minor = MINOR(inode->i_rdev);
lv_t *lv_ptr;
vg_t *vg_ptr = vg[VG_BLK(minor)];
P_DEV("blk_open MINOR: %d VG#: %d LV#: %d mode: %s%s\n",
minor, VG_BLK(minor), LV_BLK(minor),
MODE_TO_STR(file->f_mode));
#ifdef LVM_TOTAL_RESET
if (lvm_reset_spindown > 0)
return -EPERM;
#endif
if (vg_ptr != NULL &&
(vg_ptr->vg_status & VG_ACTIVE) &&
.../...
At this point, no association have been made. That is VG_BLK(minor)
will return vg_lv_map[minor].vg_number which has been initialized
to ABS_MAX_VG in lvm_init_vars().
That means that vg_ptr is set to vg[ABS_MAX_VG], which is right outside
the array bounds, as vg is declared to be
/* volume group descriptor area pointers */
vg_t *vg[ABS_MAX_VG];
So, as soon as we dereference vg_ptr, we get whatever garbage is located
right after the array, and not the NULL value we would expect for a non
initialized association.
If my understanding is correct, then a simple fix would be to
/* volume group descriptor area pointers */
- vg_t *vg[ABS_MAX_VG];
+ vg_t *vg[ABS_MAX_VG+1];
though it's a bit hackish... maybe we should just test
VG_BLK < ABS_MAX_VG
Also, the loop initializing vg array to NULL can probably be removed
from lvm_init_vars as vg is part of the BSS and thus cleared by default.
Did I miss something ?
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:13 EST