linux-kernel - [sigh] binder shite is back ;-/

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 22 Dec 2011 19:58:07 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fsdevel@...r.kernel.org
Subject: [sigh] binder shite is back ;-/

Thesis: binder is a true example of what "Enterprise Quality" means.
Nothing good, that is.

Exhibit 1:
in their ->mmap() they have
        if (proc->buffer) {
                ret = -EBUSY;
                failure_string = "already mapped";
                goto err_already_mapped;
        }

        area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);
        if (area == NULL) {
                ret = -ENOMEM;
                failure_string = "get_vm_area";
                goto err_get_vm_area_failed;
        }  
        proc->buffer = area->addr;

Note that there's nothing stopping two processes from doing mmap() on the
same file at the same time.

Exhibit 2: while proc->files is set to the ->files of whoever does mmap(),
proc->tsk is set to task_struct of whoever does open().  Then
task_get_unused_fd_flags() does expand ->files after having checked
rlimit on ->tsk.

Exhibit 3:
        if (vma)
                mm = NULL;
        else   
                mm = get_task_mm(proc->tsk);    

        if (mm) {
                down_write(&mm->mmap_sem);
                vma = proc->vma;
        }
Note that proc->vma is created by whoever had done mmap(), _not_ whoever
had done open().  Not to mention that there's no reason why either task would
still have the original ->mm...

Exhibit 4: mmap that thing and then fork().  Leaving aside the joy of
getting stack dumps in your face, it will succeed.  And then when you
unmap that thing in child (or child exits, for that matter) you'll get
proc->vma = NULL.  On a live one.

Exhibit 5: while we are at it, mmap one and then munmap its middle.

As far as I can see, the basic attitude in that code is "surely, nobody
will do anything unexpected to poor li'l me".  As far as I can tell,
manipulations of descriptor tables suffer the same kind of braindamage,
etc.
--
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/