This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:
apport-collect 1775326
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
** Tags added: xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Incomplete
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 <zhao...@cn.fujitsu.com>
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 <pet...@infradead.org>
Signed-off-by: Zhao Lei <zhao...@cn.fujitsu.com>
Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Tejun Heo <hte...@gmail.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link:
http://lkml.kernel.org/r/d8a7ef9592f55224630cb26dea239f05b6398a4e.1458187654.git.zhao...@cn.fujitsu.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
[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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
