湘北三井同学 ffffffc0000b62e8 T ns_capable ffffffc001ce8000 A swapper_pg_dir 竞争上了，但还是提不了权[em_85]，buffer data已经被 ...

需要理解下内核镜像攻击的原理。

是个狼灭，牛，支持一下，文章很赞！

jltxgcy 需要理解下内核镜像攻击的原理。

谢谢，我看看去。之前都没接触过Linux系统，就让搞这个，底层原理更是一无所知

湘北三井同学 谢谢，我看看去。之前都没接触过Linux系统，就让搞这个，底层原理更是一无所知[em_85]

昨天看了一下，算出的fake_d_block还有偏移应该没什么问题，堆喷占位也成功了，但对binder机制不是很熟悉，mediaPlayer->setPlaybackSettings(rate)设置参数这里一直返回-2147483648，然后copy_from_user里也没有拷贝我们设置的参数

大神，我也在研究这个漏洞，但没有成功，能不能交流一下，微信cherry20207788。

大佬，setDataSource时候有方案能绕过SELinux吗

湘北三井同学 大佬，setDataSource时候有方案能绕过SELinux吗

是的，最初我做的时候把SELinux的代码给注释掉了，所以能用，后来就忘记绕过这块了。你研究下吧，有解决方案也分享下。

jltxgcy 是的，最初我做的时候把SELinux的代码给注释掉了，所以能用，后来就忘记绕过这块了。你研究下吧，有解决方案也分享下。

今天试了自己的binderservice在addservice时候还是会触发SELinux,然后看了mediaserver.te里的权限，把mp4放到sdcard里就能设置上了，但现在时间间隔从之前两三百到一千五六百，而且浮动特别大，不知道是不是我改了源码的原因，明天再看看

湘北三井同学 今天试了自己的binderservice在addservice时候还是会触发SELinux,然后看了mediaserver.te里的权限，把mp4放到sdcard里就能设置上了，但现在时间间隔从之前两 ...

 我只在setDataSource时候遇到过SELinux问题，在其他处没有遇到。

很费劲的看了这个洞的利用，试了很多次类似楼主的做法，没成功过，在我的设备上，内核里面打了日志粗略的算了算，binder_buffer的alloc和free操作花费的时间基本上都是us级别的，而从内核日志上观察到alloc线程开始做alloc以及free线程开始做free操作，这俩操作的时间差别是ms级别，所以，时间上很难做调整，race起来应该很困难。不过，最后还是找到了一个方法可以把alloc线程做alloc的时间扩大到几十s，因为alloc期间有的情况下会争用mm->mmap_sem，可以用mmap不断争用这个锁，直接把alloc操作扩大到几十s，随后再去搞free，成功率会高很多。

wule 很费劲的看了这个洞的利用，试了很多次类似楼主的做法，没成功过，在我的设备上，内核里面打了日志粗略的算了算，binder_buffer的alloc和free操作花费的时间基本上都是us级别的，而从内核日 ...

感谢分享，有空我也试试。

wule 很费劲的看了这个洞的利用，试了很多次类似楼主的做法，没成功过，在我的设备上，内核里面打了日志粗略的算了算，binder_buffer的alloc和free操作花费的时间基本上都是us级别的，而从内核日 ...

已经尝试了这个方法。
首先，down_write(&mm->mmap_sem)是在binder_update_page_range申请一个新页面时调用的。但在较新的内核中，binder已经加入了内存shrink回收机制，废弃的页面将由shrink进行回收而不是立刻回收。这就意味着想要触发down_write(&mm->mmap_sem)必须是在首次申请一个新页面的时候。
然后，想要触发漏洞，buffer->allow_user_free被预置为1也是个必要条件，否则FREE的时候不会成功，360PPT的方法是通过对buffer的预先使用，使用完成后binder_thread_read中将其置为1。但是如果也采用这个方法，就会导致新页面也被提前触发使用，导致进行漏洞触发时，down_write(&mm->mmap_sem)无法被调用。
所以在较新的内核中，这种方法似乎不具有实用性，但在较老的没有shrink的内核中还是能取得效果。
或许说得有不对的地方，或是有别的更巧妙方式来触发，希望大佬指正，谢谢。

这个其实不一定，你先用一个小的size去完成置1，然后后面申请一个大的size内存，让这个大内存横跨两个page，自然就可以down_write了。后面的这个page就是要分配的，好像和shrink没啥关系。

wule 这个其实不一定，你先用一个小的size去完成置1，然后后面申请一个大的size内存，让这个大内存横跨两个page，自然就可以down_write了。后面的这个page就是要分配的，好像和shrink没 ...

这个思路挺不错，可惜binder_alloc_new_buf_locked限定了最小size为8:
/* Pad 0-size buffers so they get assigned unique addresses */
       size = max(size, sizeof(void *));
360给出的信息泄露方式也是用的这个最小size,已经没法再分割出更小的size了。
所以要继续走这条路，就得找完全不一样的信息泄露方法了。

wule 这个其实不一定，你先用一个小的size去完成置1，然后后面申请一个大的size内存，让这个大内存横跨两个page，自然就可以down_write了。后面的这个page就是要分配的，好像和shrink没 ...

shrink的问题再解释下。
新内核（pixel2） binder_update_page_range 里的代码：
for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {
               page = &alloc->pages[(page_addr - alloc->buffer) / PAGE_SIZE];
               if (!page->page_ptr) {
                       need_mm = true;
                       break;
               }
       }

       /* Same as mmget_not_zero() in later kernel versions */
       if (need_mm && atomic_inc_not_zero(&alloc->vma_vm_mm->mm_users))
               mm = alloc->vma_vm_mm;

       if (mm) {
               down_write(&mm->mmap_sem);
               vma = alloc->vma;
       }
       
只要page->page_ptr还存在，就不需要走mm那套流程，而是走lru内存管理机制那套流程。
只有第一次申请页面时，page->page_ptr才是为空，之后这个页就算废弃了，也没有真正释放，当然也不会清空，伪释放流程的代码同样是在binder_update_page_range的末尾：
free_range:
       for (page_addr = end - PAGE_SIZE; page_addr >= start;
            page_addr -= PAGE_SIZE) {
               bool ret;
               size_t index;

               index = (page_addr - alloc->buffer) / PAGE_SIZE;
               page = &alloc->pages[index];

               trace_binder_free_lru_start(alloc, index);

               ret = list_lru_add(&binder_alloc_lru, &page->lru);
               WARN_ON(!ret);

               trace_binder_free_lru_end(alloc, index);
               continue;

err_vm_insert_page_failed:
               unmap_kernel_range((unsigned long)page_addr, PAGE_SIZE);
err_map_kernel_failed:
               __free_page(page->page_ptr);
               page->page_ptr = NULL;
err_alloc_page_failed:
err_page_ptr_cleared:
               ;
       }
err_no_vma:
       if (mm) {
               up_write(&mm->mmap_sem);
               mmput(mm);
       }
       return vma ? -ENOMEM : -ESRCH;
       
       
注意那个continue 这导致代码不会走到之后的释放，清空流程。

所以不论是临界page,还是横跨page,只要这个页面被用了一次，就没法真正清空了，下次用就没法走mm信号量流程了。
要清空的话，只有系统判断内存不足或者别的什么情况，这就是shrink了，binder是注册了这个机制的，就是刚才说的那个lru链表，在这里注册的：
void binder_alloc_shrinker_init(void)
{
       list_lru_init(&binder_alloc_lru);
       register_shrinker(&binder_shrinker);
}

https://labs.bluefrostsecurity.de/files/OffensiveCon2020_bug_collision_tale.pdf

https://labs.bluefrostsecurity.de/publications/2020/03/30/a-bug-collision-tale， 大佬这种利用方式有研究过嘛？网上找了下poc没找到，想研究下这种方式

牛maomao https://labs.bluefrostsecurity.de/files/OffensiveCon2020_bug_collision_tale.pdf

大佬，这种利用方式使用binder_node 做uaf的有poc代码不，想研究下

大佬，能不能分享下二进制文件，编译太麻烦了，我也是sailfish机型

kasa_ 大佬，这种利用方式使用binder_node 做uaf的有poc代码不，想研究下

你可以直接去看CVE-2020-0041的利用

大佬，这个swapper_pg_dir在android8开启kaslr以后，原exp里面如果没有泄露的话是不是就没办法用了？