Quoting Nathan Lynch (ntl@xxxxxxxxx):
> In a checkpoint image I noticed a lot of 0x6b (POISON_FREE) bytes
> corresponding to checkpoint_restart_block -- this indicates that we
> would write uninitialized kernel memory to the image in cases where
> slab allocator debugging is not enabled[1].
>
> Use kzalloc in ckpt_hdr_get.
Yikes, yes, that's on par with a recent ecryptfs bug that did the
same thing.
Have you audited for other such potential privileged data leaks?
(besides "all sysvipc" which we know about :)
thanks,
-serge
> [1] slub's debug mode apparently initializes allocated buffers to
> POISON_FREE instead of POISON_INUSE, which confused me for a bit.
> Maybe I don't understand the intended meanings of the poison values.
>
> Signed-off-by: Nathan Lynch <ntl@xxxxxxxxx>
> ---
> checkpoint/sys.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/checkpoint/sys.c b/checkpoint/sys.c
> index 255ebc1..34a226c 100644
> --- a/checkpoint/sys.c
> +++ b/checkpoint/sys.c
> @@ -117,7 +117,7 @@ int ckpt_kread(struct ckpt_ctx *ctx, void *addr, int count)
> */
> void *ckpt_hdr_get(struct ckpt_ctx *ctx, int len)
> {
> - return kmalloc(len, GFP_KERNEL);
> + return kzalloc(len, GFP_KERNEL);
> }
>
> /**
> --
> 1.6.0.6
>
> _______________________________________________
> Containers mailing list
> Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
