cloudfuzz / android-kernel-exploitation

Android Kernel Exploitation
https://cloudfuzz.github.io/android-kernel-exploitation/
GNU General Public License v3.0
577 stars 89 forks source link

[-] writev failed. nBytesWritten: 0x1000, expected: 0x2000 #12

Open llllIIIllll opened 1 year ago

llllIIIllll commented 1 year ago
> 1|generic_x86_64:/data/local/tmp $ ./cve-2019-2215-exploit                                                     
> [+] Binding to 0th core
> [+] Opening: /dev/binder
>   [*] m_binder_fd: 0x3
> [+] Creating event poll
>   [*] m_epoll_fd: 0x4
> [+] Setting up pipe
>   [*] Pipe created successfully
>   [*] Changed the pipe capacity to: 0x1000
> [+] Setting up iovecs
> [+] Mapping 4GB aligned page
>   [*] Mapped page: 0x100000000
> [+] Linking eppoll_entry->wait.entry to binder_thread->wait.head
> [+] Freeing binder_thread
> [+] Un-linking eppoll_entry->wait.entry from binder_thread->wait.head
>   [-] writev failed. nBytesWritten: 0x1000, expected: 0x2000
> 1|generic_x86_64:/data/local/tmp $ uname -a                                                                    
> Linux localhost 4.14.150+ #1 SMP PREEMPT Wed Sep 6 22:18:47 JST 2023 x86_64

Hi, It seem to failed,how to solve it?

hacksysteam commented 1 year ago

@llllIIIllll did you try multiple times and make sure you added the patches properly? this could be a failed exploit attempt or vulnerability introduction patches are missing

llllIIIllll commented 1 year ago
 git status
Not currently on any branch.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   drivers/android/binder.c
    modified:   lib/iov_iter.c

no changes added to commit (use "git add" and/or "git commit -a")
/workshop/android-4.14-dev/goldfish$ git diff
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f6ddec24..55e2748a 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4768,10 +4768,12 @@ static int binder_thread_release(struct binder_proc *proc,
         * waitqueue_active() is safe to use here because we're holding
         * the inner lock.
         */
+       /*
        if ((thread->looper & BINDER_LOOPER_STATE_POLL) &&
            waitqueue_active(&thread->wait)) {
                wake_up_poll(&thread->wait, POLLHUP | POLLFREE);
        }
+       */

        binder_inner_proc_unlock(thread->proc);

@@ -4781,8 +4783,10 @@ static int binder_thread_release(struct binder_proc *proc,
         * descriptor being closed); ep_remove_waitqueue() holds an RCU read
         * lock, so we can be sure it's done after calling synchronize_rcu().
         */
+       /*
        if (thread->looper & BINDER_LOOPER_STATE_POLL)
                synchronize_rcu();
+       */

        if (send_reply)
                binder_send_failed_reply(send_reply, BR_DEAD_REPLY);
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 7b2fd5f2..67af6163 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -132,19 +132,21 @@

 static int copyout(void __user *to, const void *from, size_t n)
 {
-       if (access_ok(VERIFY_WRITE, to, n)) {
+       /*if (access_ok(VERIFY_WRITE, to, n)) {
                kasan_check_read(from, n);
                n = raw_copy_to_user(to, from, n);
-       }
+       }*/
+       n = raw_copy_to_user(to, from, n);
        return n;
 }

 static int copyin(void *to, const void __user *from, size_t n)
 {
-       if (access_ok(VERIFY_READ, from, n)) {
+       /*if (access_ok(VERIFY_READ, from, n)) {
                kasan_check_write(to, n);
                n = raw_copy_from_user(to, from, n);
-       }
+       }*/
+       n = raw_copy_from_user(to, from, n);
        return n;
 }

Now cve-2019-2215-trigger file can trigger, but cve-2019-2215-exploit doesn't exploit.

hacksysteam commented 1 year ago

@llllIIIllll did you give enough cores to the emulator?

llllIIIllll commented 1 year ago
generic_x86_64:/ $ cat /proc/cpuinfo | grep processor | wc -l 
4

Cores are 4.

hacksysteam commented 1 year ago

@llllIIIllll Interesting.

[+] Un-linking eppoll_entry->wait.entry from binder_thread->wait.head [-] writev failed. nBytesWritten: 0x1000, expected: 0x2000 1|generic_x86_64:/data/local/tmp $ uname -a

this error means that the exploit attempt has failed. few months back I checked the exploit and it worked. Can you just build the kernel with KASAN and see if the crash occurs?

llllIIIllll commented 1 year ago
[  243.010266] BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x3a/0x5d
[  243.010266] Write of size 4 at addr ffff88802caf80a8 by task cve-2019-2215-t/5323
[  243.010266] 
[  243.010266] CPU: 1 PID: 5323 Comm: cve-2019-2215-t Tainted: G        W       4.14.150+ #1
[  243.010266] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
[  243.010266] Call Trace:
[  243.010266]  dump_stack+0x7d/0xc4
[  243.010266]  print_address_description+0x84/0x260
[  243.050408]  ? _raw_spin_lock_irqsave+0x3a/0x5d
[  243.050408]  __kasan_report+0x15b/0x18c
[  243.050408]  ? _raw_spin_lock_irqsave+0x3a/0x5d
[  243.050408]  kasan_report+0x26/0x49
[  243.050408]  check_memory_region+0x15d/0x16a
[  243.050408]  kasan_check_write+0x14/0x16
[  243.070522]  _raw_spin_lock_irqsave+0x3a/0x5d
[  243.070522]  remove_wait_queue+0x27/0x122
[  243.070522]  ? fsnotify_unmount_inodes+0x1e8/0x1e8
[  243.070522]  ep_unregister_pollwait+0x168/0x1c0
[  243.070522]  ep_free+0x9a/0x17d
[  243.070522]  ? ep_eventpoll_poll+0x228/0x228
[  243.070522]  ep_eventpoll_release+0x48/0x54
[  243.070522]  __fput+0x1f2/0x51f
[  243.070522]  ____fput+0x15/0x18
[  243.070522]  task_work_run+0x95/0x153
[  243.070522]  do_exit+0x99b/0x2621
[  243.070522]  ? kasan_slab_free+0xe/0x10
[  243.070522]  ? check_preemption_disabled+0x38/0x203
[  243.070522]  ? remove_vma+0xfe/0x10a
[  243.070522]  ? kasan_check_read+0x11/0x13
[  243.070522]  ? prepare_exit_to_usermode+0x101/0x272
[  243.120363]  ? mm_update_next_owner+0x6cb/0x6cb
[  243.120363]  ? syscall_return_slowpath+0xbc/0x4dd
[  243.120363]  ? do_munmap+0x8ec/0x991
[  243.120363]  ? prepare_exit_to_usermode+0x272/0x272
[  243.120363]  ? vm_munmap+0x124/0x166
[  243.120363]  do_group_exit+0x12c/0x24b
[  243.120363]  SYSC_exit_group+0x17/0x17
[  243.120363]  SyS_exit_group+0x14/0x14
[  243.120363]  ? do_group_exit+0x24b/0x24b
[  243.120363]  do_syscall_64+0x19c/0x1e4
[  243.120363]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  243.120363] RIP: 0033:0x4047d7
[  243.120363] RSP: 002b:00007ffec3bca1f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[  243.120363] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004047d7
[  243.120363] RDX: 0000000000000002 RSI: 0000000000001000 RDI: 0000000000000000
[  243.120363] RBP: 0000000000000000 R08: 0000000000482335 R09: 0000000000000000
[  243.120363] R10: 00007ffec3bca1f0 R11: 0000000000000246 R12: 0000000000400190
[  243.120363] R13: 00000000004a4618 R14: 00000000004002e0 R15: 00007ffec3bca2c0
[  243.120363] 
[  243.190326] Allocated by task 5323:
[  243.190326]  save_stack_trace+0x16/0x18
[  243.190326]  __kasan_kmalloc+0x134/0x1c8
[  243.190326]  kasan_kmalloc+0x9/0xb
[  243.200291]  kmem_cache_alloc_trace+0x1d6/0x2c0
[  243.200291]  binder_get_thread+0x167/0x6dd
[  243.200291]  binder_poll+0x4c/0x1c2
[  243.200291]  SyS_epoll_ctl+0x1568/0x2509
[  243.200291]  do_syscall_64+0x19c/0x1e4
[  243.200291]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  243.200291]  0xffffffffffffffff
[  243.220319] 
[  243.220319] Freed by task 5323:
[  243.220319]  save_stack_trace+0x16/0x18
[  243.220319]  __kasan_slab_free+0x18e/0x236
[  243.220319]  kasan_slab_free+0xe/0x10
[  243.230280]  kfree+0x153/0x632
[  243.230280]  binder_thread_dec_tmpref+0x240/0x2d5
[  243.240210]  binder_thread_release+0x464/0x4bd
[  243.240210]  binder_ioctl+0x50e/0x1175
[  243.240210]  do_vfs_ioctl+0x5fa/0x1127
[  243.240210]  SyS_ioctl+0x75/0xa4
[  243.240210]  do_syscall_64+0x19c/0x1e4
[  243.240210]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  243.240210]  0xffffffffffffffff
[  243.240210] 
[  243.240210] The buggy address belongs to the object at ffff88802caf8008
[  243.240210]  which belongs to the cache kmalloc-512 of size 512
[  243.240210] The buggy address is located 160 bytes inside of
[  243.240210]  512-byte region [ffff88802caf8008, ffff88802caf8208)
[  243.240210] The buggy address belongs to the page:
[  243.240210] page:ffffea0000b2be00 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
[  243.240210] flags: 0x4000000000010200(slab|head)
[  243.240210] raw: 4000000000010200 0000000000000000 0000000000000000 0000000100120012
[  243.240210] raw: ffffea0000cec720 ffffea0000e3b420 ffff88805ac0cf40 0000000000000000
[  243.300441] page dumped because: kasan: bad access detected
[  243.310315] 
[  243.310315] Memory state around the buggy address:
[  243.310315]  ffff88802caf7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  243.310315]  ffff88802caf8000: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  243.310315] >ffff88802caf8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  243.310315]                                   ^
[  243.310315]  ffff88802caf8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  243.310315]  ffff88802caf8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  243.310315] ==================================================================
[  243.310315] Disabling lock debugging due to kernel taint

This is very strange

hacksysteam commented 1 year ago

@llllIIIllll this is very strange. One more thing you should check is if reallocation is happening correctly

llllIIIllll commented 1 year ago

Thank you. I'll try again. If I have any more questions, I'll come to bother you again