Possible LVM bug in 2.4.19-rc1

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.