Re: [PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephen,

On 2015/1/23 3:05, Stephen Smalley wrote:
On Wed, Jan 21, 2015 at 9:44 PM, Ethan Zhao <ethan.kernel@xxxxxxxxx> wrote:
On Wed, Jan 21, 2015 at 1:30 PM, Manfred Spraul
<manfred@xxxxxxxxxxxxxxxx> wrote:
On 01/21/2015 04:53 AM, Ethan Zhao wrote:
On Tue, Jan 20, 2015 at 10:10 PM, Stephen Smalley <sds@xxxxxxxxxxxxx>
wrote:
On 01/20/2015 04:18 AM, Ethan Zhao wrote:
       sys_semget()
       ->newary()
           ->security_sem_alloc()
             ->sem_alloc_security()
                   selinux_sem_alloc_security()
                   ->ipc_alloc_security() {
                     ->rc = avc_has_perm()
                                if (rc) {

ipc_free_security(&sma->sem_perm);
                                        return rc;
We free the security structure here to avoid a memory leak on a
failed/denied semaphore set creation.  In this situation, we return an
error to the caller (ultimately to newary), it does an
ipc_rcu_putref(sma, ipc_rcu_free), and it returns an error to the
caller.  Thus, it never calls ipc_addid() and the semaphore set is not
created.  So how then can you call semtimedop() on it?
Seems it wouldn't happen after commit
e8577d1f0329d4842e8302e289fb2c22156abef4 ?
That was my first guess when I read the bug report - but it can't be the
fix, because security_sem_alloc() is before the ipc_addid(), with or without
the patch.

thread A:
             thread B:

semtimedop()
-> sem_obtain_object_check()
             semctl(IPC_RMID)
             -> freeary()
             -> ipc_rcu_putref()
             -> call_rcu()
-> somehow a grace period
             -> sem_rcu_free()
             -> security_sem_free()

Perhaps: modify ipc_free_security() to hexdump perm and a few more bytes if
the pointer is NULL?
I tried to ask for vmcore and do more analysis, basically, the race condition
still exists and open a hole to be DoS.
You said the patch was tested with 3.19-rc5.
 I just threw the 3.19-rc5 with my test patch to the 'user', he said he
 doesn't hit. maybe he didn't hit or occasionally failed to reproduce it.
  But did you reproduce
the bug on that kernel version before the patch?
 Good news is not hit yet.

  If not, what kernel
version were you running when you triggered the bug?
To be honest, a kernel from distro, but not released, but before we get it clear, we wouldn't public more.

 Thanks,
 Ethan


_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux