[sigh] binder shite is back ;-/

* [sigh] binder shite is back ;-/
@ 2011-12-22 19:58 Al Viro
  2011-12-22 20:51 ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2011-12-22 19:58 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-fsdevel

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread