On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote:
> On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote:
>
> > Two things are at risk from stack exhaustion: thread_info (mainly
> > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and
>
> Really? Let's take a look at arm, for example:
>
> struct thread_info {
> unsigned long flags; /* low level flags */
> int preempt_count; /* 0 => preemptable,
> <0 => bug */
> mm_segment_t addr_limit; /* address limit */
> struct task_struct *task; /* main task
> structure */
>
> and current() is defined as current_thread_info()->task.
>
> Seriously, look at these beasts. Overwriting ->addr_limit is nowhere
> near
> the top threat. If attacker can overwrite thread_info, you have
> lost.
That is why THREAD_INFO_IN_TASK exists. It moves
the struct thread_info to a location away from the
stack, which means a stack overflow will not overwrite
the thread_info.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
