Open llllIIIllll opened 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
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.
@llllIIIllll did you give enough cores to the emulator?
generic_x86_64:/ $ cat /proc/cpuinfo | grep processor | wc -l
4
Cores are 4.
@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?
[ 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
@llllIIIllll this is very strange. One more thing you should check is if reallocation is happening correctly
Thank you. I'll try again. If I have any more questions, I'll come to bother you again
Hi, It seem to failed,how to solve it?