Re: [PATCH] c/r: Initialize msg_msg security pointer at restart.

["Jose R. Santos" <jrs-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

On Wed, 30 Mar 2011 22:29:54 -0500
"Serge E. Hallyn" <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> wrote:

> Quoting Jose R. Santos (jrs-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> > This small oversight was causing either crashes on free_msg() or
> > restart failures under some message queue workloads.
> > 
> > Signed-off-by: Jose R. Santos <jrs-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> 
> What kernel is this?

ckpt-v23-rc1

> Starting with the last line in your context, there is:
> 
> 	/* set default MAC attributes */
> 	ret = security_msg_msg_alloc(msg);
> 	if (ret < 0)
> 		goto out;
> 
> which should take care of that.  I don't know of an LSM which
> doesn't define msg_msg_alloc() but does define msg_msg_free().
> Do you have a stack trace to show where it was getting
> freed?

Sorry, should have put more details in the patch description.  The
problem here is that msg_msg_alloc() in not allocating anything and
thus the msg->security just happens to have what ever random data
that happens to be there after kmalloc was called for this msg. So the
way this usually manifested was during the a second checkpoint/restart.
For example:

run ./mq_test
checkpoint:
	Saving the msg with SECURITY_NONE
restart:
	Restores the msg content but with msg->security set to
	something random (or 0x5a pattern if using DEBUG_SLAB)
second checkpoint:
	msg->security not NULL so we proceed in
	security_checkpoint_obj() to call security_msg_msg_checkpoint()
second restart:
	All sorts of very weird, very different, hard to debug stuff
	happens afterwards. :)

Also, If you look at load_msg() in msgutil.c, the msg->security is also
initialized to NULL _before_ calling security_msg_msg_alloc().  Hope
this explains this fix better.

-JRS