Re: [PATCH] Set hard limit on delta chain depth

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2011, 00:02 UTC
Message-ID: <7vsjktb8fo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8AZg3DgZzmPyXhCH9bGBqo9UN7-zLt_feTtpyajf5U1tw@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> That's interesting. First of all xmalloc() is controlled by us while
> index-pack code might lead to stack overflow exploit (never done it,
> not sure if it's really pratical to do in this case).

What do you exactly mean by "stack overflow exploit"?

If your callee has prepares a stackframe that is not sufficiently big but carelessly tries to store more than it has space for, such a write can overflow the stack (without hardware traps) and overwrite return address, and instead of coming back to you, the control can be transferred to random places.

But I do not think that is what we are talking about here.

You attempt to write parameters and return address to the area of memory pointed by your stack pointer, advance the stack pointer to create a stack frame and the callee attempts to write to its local variables in the newly allocated stack frame. These memory accesses eventually attempt to touch memory beyond the address range the kernel gave you page table entries to be used as your stack space, and hardware traps. If you haven't run out of the stack, a new page is lazily added to the page table and your attempted access will succeed. If you are recursing too deeply, you won't be given a new page and you will be killed by the kernel. That is a rather controlled death of the process, unlike smashing the contents of the stack to jump to a randomly chosen place, isn't it?

Of course, some platforms do not have an unwritable gap between the stack segment that grow downwards and the heap that grow upwards, and also your stackframe could be larger than such a gap (in this particular callchain I do not think that is the case), so the above discussion does not apply universally, though.