group.of.nepali.translators team mailing list archive

["Guilherme G. Piccoli" <1775326@xxxxxxxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu)
       Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1775326

Title:
  The kernel NULL pointer dereference happens when accessing the
  task_struct by task_cpu() in function cpuacct_charge()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  In function cpuacct_charge(), the NULL pointer dereference happens
  with the stack pointer being zero inside the task_struct when the
  task_cpu() is trying to access the member CPU of the struct
  thread_info inside the stack. It's a use-after-free corruption
  happening in the situation that the task_struct is released almost
  concurrently before accessing the task_struct->stack.

  void cpuacct_charge(struct task_struct *tsk, u64 cputime)
   {
          struct cpuacct *ca;
          int cpu;
   
          cpu = task_cpu(tsk);
   
          rcu_read_lock();
   
          ca = task_ca(tsk);
   
          while (true) {
                  u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
                  *cpuusage += cputime;
   
                  ca = parent_ca(ca);
                  if (!ca)
                          break;
          }

  	rcu_read_unlock();
  }

  
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
  IP: [<ffffffff810c3ff4>] cpuacct_charge+0x14/0x40
  PGD 0 
  Oops: 0000 [#1] SMP  
  CPU: 10 PID: 148614 Comm: qemu-system-x86 Tainted: P        W  OE   4.4.0-45-generic #66~14.04.1-Ubuntu
  Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.7 06/16/2016
  task: ffff881ff0f01b80 ti: ffff88018fd70000 task.ti: ffff88018fd70000
  RIP: 0010:[<ffffffff810c3ff4>]  [<ffffffff810c3ff4>] cpuacct_charge+0x14/0x40
  RSP: 0018:ffff88018fd73d10  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff8801931e8000 RCX: ffff88010caff200
  RDX: ffff880124508000 RSI: 0066f757398831d6 RDI: ffff8801931e7fa0
  RBP: ffff88018fd73d10 R08: ffffffffc04b8320 R09: 0000000000000001
  R10: 0000000000000001 R11: 0000000000000000 R12: 0066f757398831d6
  R13: 0066f757398b8997 R14: ffff8801931e7fa0 R15: 0000000000000001
  FS:  00007f162aaf7700(0000) GS:ffff881ffe740000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000010 CR3: 000000011d86e000 CR4: 00000000003426e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Stack:
   ffff88018fd73d28 ffffffff810b1a9f ffff8801931e8000 ffff88018fd73d40
   ffffffffc069df72 ffff8801931e8000 ffff88018fd73da8 ffffffffc069f121
   ffff881ff0f01b80 0000000000000000 ffff881ff0f01b80 ffffffff810bddc0
  Call Trace:
   [<ffffffff810b1a9f>] update_curr+0xdf/0x170
   [<ffffffffc069df72>] kvm_vcpu_check_block+0x12/0x60 [kvm]
   [<ffffffffc069f121>] kvm_vcpu_block+0x191/0x2d0 [kvm]
   [<ffffffff810bddc0>] ? prepare_to_wait_event+0xf0/0xf0
   [<ffffffffc06bb9ee>] kvm_arch_vcpu_ioctl_run+0x17e/0x3d0 [kvm]
   [<ffffffffc06a1f8b>] kvm_vcpu_ioctl+0x2ab/0x640 [kvm]
   [<ffffffff81174517>] ? perf_event_context_sched_in+0x87/0xa0
   [<ffffffff81210d6d>] do_vfs_ioctl+0x2dd/0x4c0
   [<ffffffff8111fa1f>] ? __audit_syscall_entry+0xaf/0x100
   [<ffffffff81003176>] ? do_audit_syscall_entry+0x66/0x70
   [<ffffffff81210fc9>] SyS_ioctl+0x79/0x90
   [<ffffffff817fa4f6>] entry_SYSCALL_64_fastpath+0x16/0x75
  Code: 9a 11 00 5b 48 c7 c0 f4 ff ff ff 5d eb df 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 08 48 8b 97 78 07 00 00 48 89 e5 <48> 63 48 10 48 8b 52 60 48 8b 82 b8 00 00 00 48 03 04 cd c0 7a
  RIP  [<ffffffff810c3ff4>] cpuacct_charge+0x14/0x40
   RSP <ffff88018fd73d10>
  CR2: 0000000000000010
  ---[ end trace 419a30375d0e4622 ]---


  [Fix]

  The patch uses this_cpu_ptr() instead of getting the CPU number by 
  task_cpu() and proceeds to get the cpu_usage by per_cpu_ptr(). And
  that can avoid accessing the thread_info inside the stack. 

  commit 73e6aafd9ea81498d31361f01db84a0118da2d1c
  Author: Zhao Lei <zhaolei@xxxxxxxxxxxxxx>
  Date:   Thu Mar 17 12:19:43 2016 +0800

      sched/cpuacct: Simplify the cpuacct code
      
       - Use for() instead of while() loop in some functions
         to make the code simpler.
      
       - Use this_cpu_ptr() instead of per_cpu_ptr() to make the code
         cleaner and a bit faster.
      
      Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
      Signed-off-by: Zhao Lei <zhaolei@xxxxxxxxxxxxxx>
      Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
      Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
      Cc: Tejun Heo <htejun@xxxxxxxxx>
      Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
      Link: http://lkml.kernel.org/r/d8a7ef9592f55224630cb26dea239f05b6398a4e.1458187654.git.zhaolei@xxxxxxxxxxxxxx
      Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>


  [Test]
  The test kernel has been tested by the Qemu and cannot be reproduced.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1775326/+subscriptions