Re: [CHECKER] 32 Memory Leaks on Error Paths

[Andries Brouwer]

On Mon, Sep 15, 2003 at 09:35:46PM -0700, David Yu Chen wrote:

> I'm with the Stanford Meta-level Compilation research group, and I
> have a set of memory leaks on error paths for the 2.6.0-test5 kernel.

There is no memory leak in the below:

> ---------------------------------------------------------
> 
> [FILE:  2.6.0-test5/drivers/char/vt_ioctl.c]
> [FUNC:  do_kdsk_ioctl]
> [LINES: 133-150]
> [VAR:   key_map]
>  128:
>  129:			if (keymap_count >= MAX_NR_OF_USER_KEYMAPS &&
>  130:			    !capable(CAP_SYS_RESOURCE))
>  131:				return -EPERM;
>  132:
> START -->
>  133:			key_map = (ushort *) kmalloc(sizeof(plain_map),
>  134:						     GFP_KERNEL);
>  135:			if (!key_map)
>  136:				return -ENOMEM;
>  137:			key_maps[s] = key_map;
>  138:			key_map[0] = U(K_ALLOCATED);
>         ... DELETED 6 lines ...
>  145:			break;	/* nothing to do */
>  146:		/*
>  147:		 * Attention Key.
>  148:		 */
>  149:		if (((ov == K_SAK) || (v == K_SAK)) && !capable(CAP_SYS_ADMIN))
> END -->
>  150:			return -EPERM;
>  151:		key_map[i] = U(v);
>  152:		if (!s && (KTYP(ov) == KT_SHIFT || KTYP(v) == KT_SHIFT))
>  153:			compute_shiftstate();
>  154:		break;
>  155:	}

Explanation:
The user may have up to 256 keymaps, namely the plain map and
various maps for (combinations of) modifier keys.
In order to save memory, most of these keymaps will not be allocated.
If one sets an entry on a keymap, then first the keymap itself is
allocated in case it did not exist yet. Then the entry is filled,
assuming one has permission.
On the error path the memory is not lost: the pointer was stored
in the array key_maps[], so also am automatic checker could see that.
(And indeed, it is also possible to deallocate keymaps.)

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/