linux-kernel - Re: [BUG] signal: sighand unprotected when accessed by /proc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140603172632.GA27956@redhat.com>
Date:	Tue, 3 Jun 2014 19:26:32 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Clark Williams <williams@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [BUG] signal: sighand unprotected when accessed by /proc

On 06/03, Steven Rostedt wrote:
>
> We were able to trigger this bug in -rt, and by review, I'm thinking
> that this could very well be a mainline bug too. I had our QA team add
> a trace patch to the kernel to prove my analysis, and it did.
>
> Here's the patch:
>
>  http://rostedt.homelinux.com/private/sighand-trace.patch
>
> Let me try to explain the bug:
>
>
> 	CPU0				CPU1
> 	----				----
>  [ read of /proc/<pid>/stat ]
>   get_task_struct();
>   [...]
> 				  [ <pid> exits ]
> 				  [ parent does wait on <pid> ]
> 				  wait_task_zombie()
> 				    release_task()
> 				      proc_flush_task()
> 				      /* the above removes new access
> 				         to the /proc system */
> 				      __exit_signal()
> 				        __cleanup_sighand(sighand);
> 					  atomic_dec_and_test(sighand->count);
>   do_task_stat()
>     lock_task_sighand(task);
>       sighand = rcu_dereference(tsk->sighand);
>
> 					    kmem_cache_free(sighand);
>
>       if (sighand != NULL)
>         spin_lock(sighand->siglock);
>
>        ** BOOM! use after free **

Yes, ->sighand can be already freed at this point, but this should be
fine because sighand_cachep is SLAB_DESTROY_BY_RCU.

That is why lock_task_sighand() does rcu_read_lock() and re-checks
sighand == tsk->sighand after it takes ->siglock. It is fine if it was
already freed or even reallocated via kmem_cache_alloc(sighand_cachep).
We only need to ensure that (SLAB_DESTROY_BY_RCU should ensure this)
this memory won't be returned to system, so this peace of memory must
be "struct sighand" with the properly initialized ->siglock until
rcu_read_unlock().

> Seems there is no protection between reading the sighand from proc and
> freeing it. The sighand->count is not updated, and the sighand is not
> freed via rcu.

See above.

> One, the spinlock in -rt is an rtmutex. The list_del_entry() bug is the
> task trying to remove itself from sighand->lock->wait_list. As the lock
> has been freed, the list head of the rtmutex is corrupted.

looks like, SLAB_DESTROY_BY_RCU logic is broken?

Oleg.

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