hitoshura25/cvefixes huggingface dataset:
CVE-2015-0239 (C, published 2015-03-02T11:59Z)
Description: value: The em_sysenter function in arch/x86/kvm/emulate.c in the Linux kernel before 3.18.5, when the guest OS lacks SYSENTER MSR initialization, allows guest OS users to gain guest OS privileges or cause a denial of service (guest OS crash) by triggering use of a 16-bit code segment for emulation of a SYSENTER instruction.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-269 \u2014 Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/kvm/emulate.c
Commit message: KVM: x86: SYSENTER emulation is broken

SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
   still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
   legacy-mode.
4. There is some unneeded code.

Fix it.

Cc: stable@vger.linux.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


Vulnerable code:
	if ((ctxt->mode == X86EMUL_MODE_PROT32) && (efer & EFER_LMA)
	switch (ctxt->mode) {
	case X86EMUL_MODE_PROT32:
		if ((msr_data & 0xfffc) == 0x0)
			return emulate_gp(ctxt, 0);
		break;
	case X86EMUL_MODE_PROT64:
		if (msr_data == 0x0)
			return emulate_gp(ctxt, 0);
		break;
	default:
		break;
	}
	cs_sel = (u16)msr_data;
	cs_sel &= ~SELECTOR_RPL_MASK;
	ss_sel &= ~SELECTOR_RPL_MASK;
	if (ctxt->mode == X86EMUL_MODE_PROT64 || (efer & EFER_LMA)) {
	ctxt->_eip = msr_data;
	*reg_write(ctxt, VCPU_REGS_RSP) = msr_data;

Fixed code:
	if ((ctxt->mode != X86EMUL_MODE_PROT64) && (efer & EFER_LMA)
	if ((msr_data & 0xfffc) == 0x0)
		return emulate_gp(ctxt, 0);
	cs_sel = (u16)msr_data & ~SELECTOR_RPL_MASK;
	if (efer & EFER_LMA) {
	ctxt->_eip = (efer & EFER_LMA) ? msr_data : (u32)msr_data;
	*reg_write(ctxt, VCPU_REGS_RSP) = (efer & EFER_LMA) ? msr_data :
							      (u32)msr_data;
CVE-2017-18261 (C, published 2018-04-19T08:29Z)
Description: value: The arch_timer_reg_read_stable macro in arch/arm64/include/asm/arch_timer.h in the Linux kernel before 4.13 allows local users to cause a denial of service (infinite recursion) by writing to a file under /sys/kernel/debug in certain circumstances, as demonstrated by a scenario involving debugfs, ftrace, PREEMPT_TRACER, and FUNCTION_GRAPH_TRACER.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-835 \u2014 Loop with Unreachable Exit Condition ('Infinite Loop')
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Repository: https://github.com/torvalds/linux
Files changed:
arch/arm64/include/asm/arch_timer.h
Commit message: clocksource/drivers/arm_arch_timer: Avoid infinite recursion when ftrace is enabled

On platforms with an arch timer erratum workaround, it's possible for
arch_timer_reg_read_stable() to recurse into itself when certain
tracing options are enabled, leading to stack overflows and related
problems.

For example, when PREEMPT_TRACER and FUNCTION_GRAPH_TRACER are
selected, it's possible to trigger this with:

$ mount -t debugfs nodev /sys/kernel/debug/
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer

The problem is that in such cases, preempt_disable() instrumentation
attempts to acquire a timestamp via trace_clock(), resulting in a call
back to arch_timer_reg_read_stable(), and hence recursion.

This patch changes arch_timer_reg_read_stable() to use
preempt_{disable,enable}_notrace(), which avoids this.

This problem is similar to the fixed by upstream commit 96b3d28bf4
("sched/clock: Prevent tracing recursion in sched_clock_cpu()").

Fixes: 6acc71ccac71 ("arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs")
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>


Vulnerable code:
		preempt_disable();					\
		preempt_enable();					\

Fixed code:
		preempt_disable_notrace();				\
		preempt_enable_notrace();				\
CVE-2015-7513 (C, published 2016-02-08T03:59Z)
Description: value: arch/x86/kvm/x86.c in the Linux kernel before 4.4 does not reset the PIT counter values during state restoration, which allows guest OS users to cause a denial of service (divide-by-zero error and host OS crash) via a zero value, related to the kvm_vm_ioctl_set_pit and kvm_vm_ioctl_set_pit2 functions.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-369 \u2014 Divide By Zero
The product divides a value by zero.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/kvm/x86.c
Commit message: KVM: x86: Reload pit counters for all channels when restoring state

Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash.  This will ensure
that 0 values are converted to 65536 as per the spec.

This is CVE-2015-7513.

Signed-off-by: Andy Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


Vulnerable code:
	kvm_pit_load_count(kvm, 0, ps->channels[0].count, 0);
	kvm_pit_load_count(kvm, 0, kvm->arch.vpit->pit_state.channels[0].count, start);

Fixed code:
	int i;
	for (i = 0; i < 3; i++)
		kvm_pit_load_count(kvm, i, ps->channels[i].count, 0);
	int i;
	for (i = 0; i < 3; i++)
		kvm_pit_load_count(kvm, i, kvm->arch.vpit->pit_state.channels[i].count, start);
CVE-2012-6539 (C, published 2013-03-15T20:55Z)
Description: value: The dev_ifconf function in net/socket.c in the Linux kernel before 3.6 does not initialize a certain structure, which allows local users to obtain sensitive information from kernel stack memory via a crafted application.
Severity: LOW (CVSS v3 base score: )
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/torvalds/linux
Files changed:
net/socket.c
Commit message: net: fix info leak in compat dev_ifconf()

The implementation of dev_ifconf() for the compat ioctl interface uses
an intermediate ifc structure allocated in userland for the duration of
the syscall. Though, it fails to initialize the padding bytes inserted
for alignment and that for leaks four bytes of kernel stack. Add an
explicit memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:

Fixed code:
	memset(&ifc, 0, sizeof(ifc));
CVE-2015-5257 (C, published 2015-11-16T11:59Z)
Description: value: drivers/usb/serial/whiteheat.c in the Linux kernel before 4.2.4 allows physically proximate attackers to cause a denial of service (NULL pointer dereference and OOPS) or possibly have unspecified other impact via a crafted USB device.  NOTE: this ID was incorrectly used for an Apache Cordova issue that has the correct ID of CVE-2015-8320.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/usb/serial/whiteheat.c
Commit message: USB: whiteheat: fix potential null-deref at probe

Fix potential null-pointer dereference at probe by making sure that the
required endpoints are present.

The whiteheat driver assumes there are at least five pairs of bulk
endpoints, of which the final pair is used for the "command port". An
attempt to bind to an interface with fewer bulk endpoints would
currently lead to an oops.

Fixes CVE-2015-5257.

Reported-by: Moein Ghasemzadeh <moein@istuary.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Vulnerable code:

Fixed code:
static int whiteheat_probe(struct usb_serial *serial,
				const struct usb_device_id *id);
	.probe =		whiteheat_probe,

static int whiteheat_probe(struct usb_serial *serial,
				const struct usb_device_id *id)
{
	struct usb_host_interface *iface_desc;
	struct usb_endpoint_descriptor *endpoint;
	size_t num_bulk_in = 0;
	size_t num_bulk_out = 0;
	size_t min_num_bulk;
	unsigned int i;

	iface_desc = serial->interface->cur_altsetting;

	for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
		endpoint = &iface_desc->endpoint[i].desc;
		if (usb_endpoint_is_bulk_in(endpoint))
			++num_bulk_in;
		if (usb_endpoint_is_bulk_out(endpoint))
			++num_bulk_out;
	}

	min_num_bulk = COMMAND_PORT + 1;
	if (num_bulk_in < min_num_bulk || num_bulk_out < min_num_bulk)
		return -ENODEV;

	return 0;
}
CVE-2011-1180 (C, published 2013-06-08T13:05Z)
Description: value: Multiple stack-based buffer overflows in the iriap_getvaluebyclass_indication function in net/irda/iriap.c in the Linux kernel before 2.6.39 allow remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging connectivity to an IrDA infrared network and sending a large integer value for a (1) name length or (2) attribute length.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/torvalds/linux
Files changed:
net/irda/iriap.c
Commit message: irda: validate peer name and attribute lengths

Length fields provided by a peer for names and attributes may be longer
than the destination array sizes.  Validate lengths to prevent stack
buffer overflows.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:

Fixed code:

	IRDA_ASSERT(name_len < IAS_MAX_CLASSNAME + 1, return;);


	IRDA_ASSERT(attr_len < IAS_MAX_ATTRIBNAME + 1, return;);
CVE-2012-0044 (C, published 2012-05-17T11:00Z)
Description: value: Integer overflow in the drm_mode_dirtyfb_ioctl function in drivers/gpu/drm/drm_crtc.c in the Direct Rendering Manager (DRM) subsystem in the Linux kernel before 3.1.5 allows local users to gain privileges or cause a denial of service (memory corruption) via a crafted ioctl call.
Severity: HIGH (CVSS v3 base score: 7.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/gpu/drm/drm_crtc.c
include/drm/drm_mode.h
Commit message: drm: integer overflow in drm_mode_dirtyfb_ioctl()

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.

Reported-by: Haogang Chen <haogangchen@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>


Vulnerable code:

Fixed code:
		if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) {
			ret = -EINVAL;
			goto out_err1;
		}
#define DRM_MODE_FB_DIRTY_MAX_CLIPS     256
CVE-2013-4220 (C, published 2013-08-25T03:27Z)
Description: value: The bad_mode function in arch/arm64/kernel/traps.c in the Linux kernel before 3.9.5 on the ARM64 platform allows local users to cause a denial of service (system crash) via vectors involving an attempted register access that triggers an unexpected value in the Exception Syndrome Register (ESR).
Severity: MEDIUM (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/torvalds/linux
Files changed:
arch/arm64/kernel/traps.c
Commit message: arm64: don't kill the kernel on a bad esr from el0

Rather than completely killing the kernel if we receive an esr value we
can't deal with in the el0 handlers, send the process a SIGILL and log
the esr value in the hope that we can debug it. If we receive a bad esr
from el1, we'll die() as before.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: stable@vger.kernel.org


Vulnerable code:
	die("Oops - bad mode", regs, 0);
	local_irq_disable();
	panic("bad mode");

Fixed code:
	siginfo_t info;
	void __user *pc = (void __user *)instruction_pointer(regs);
	__show_regs(regs);

	info.si_signo = SIGILL;
	info.si_errno = 0;
	info.si_code  = ILL_ILLOPC;
	info.si_addr  = pc;
	arm64_notify_die("Oops - bad mode", regs, &info, 0);
CVE-2011-2493 (C, published 2012-06-13T10:24Z)
Description: value: The ext4_fill_super function in fs/ext4/super.c in the Linux kernel before 2.6.39 does not properly initialize a certain error-report data structure, which allows local users to cause a denial of service (OOPS) by attempting to mount a crafted ext4 filesystem.
Severity: LOW (CVSS v3 base score: )
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/torvalds/linux
Files changed:
fs/ext4/super.c
Commit message: ext4: init timer earlier to avoid a kernel panic in __save_error_info

During mount, when we fail to open journal inode or root inode, the
__save_error_info will mod_timer. But actually s_err_report isn't
initialized yet and the kernel oops. The detailed information can
be found https://bugzilla.kernel.org/show_bug.cgi?id=32082.

The best way is to check whether the timer s_err_report is initialized
or not. But it seems that in include/linux/timer.h, we can't find a
good function to check the status of this timer, so this patch just
move the initializtion of s_err_report earlier so that we can avoid
the kernel panic. The corresponding del_timer is also added in the
error path.

Reported-by: Sami Liedes <sliedes@cc.hut.fi>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>


Vulnerable code:
	init_timer(&sbi->s_err_report);
	sbi->s_err_report.function = print_daily_error_info;
	sbi->s_err_report.data = (unsigned long) sb;

Fixed code:
	init_timer(&sbi->s_err_report);
	sbi->s_err_report.function = print_daily_error_info;
	sbi->s_err_report.data = (unsigned long) sb;

	del_timer(&sbi->s_err_report);
CVE-2014-9803 (C, published 2016-07-11T01:59Z)
Description: value: arch/arm64/include/asm/pgtable.h in the Linux kernel before 3.15-rc5-next-20140519, as used in Android before 2016-07-05 on Nexus 5X and 6P devices, mishandles execute-only pages, which allows attackers to gain privileges via a crafted application, aka Android internal bug 28557020.
Severity: HIGH (CVSS v3 base score: 7.8)
Weakness: CWE-19 \u2014 Data Processing Errors
Weaknesses in this category are typically found in functionality that processes data. Data processing is the manipulation of input to retrieve or save information.
Repository: https://github.com/torvalds/linux
Files changed:
arch/arm64/include/asm/pgtable.h
arch/arm64/mm/fault.c
Commit message: Revert "arm64: Introduce execute-only page access permissions"

This reverts commit bc07c2c6e9ed125d362af0214b6313dca180cb08.

While the aim is increased security for --x memory maps, it does not
protect against kernel level reads. Until SECCOMP is implemented for
arm64, revert this patch to avoid giving a false idea of execute-only
mappings.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


Vulnerable code:
#define PAGE_EXECONLY		__pgprot(_PAGE_DEFAULT | PTE_NG | PTE_PXN)
#define __P100  PAGE_EXECONLY
#define __S100  PAGE_EXECONLY
#define pte_valid_ng(pte) \
	((pte_val(pte) & (PTE_VALID | PTE_NG)) == (PTE_VALID | PTE_NG))
	if (pte_valid_ng(pte)) {
	 * occurred.
	unsigned long vm_flags = VM_READ | VM_WRITE;

Fixed code:
#define __P100  PAGE_READONLY_EXEC
#define __S100  PAGE_READONLY_EXEC
#define pte_valid_user(pte) \
	((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER))
	if (pte_valid_user(pte)) {
	 * occurred. If we encountered a write or exec fault, we must have
	 * appropriate permissions, otherwise we allow any permission.
	unsigned long vm_flags = VM_READ | VM_WRITE | VM_EXEC;
CVE-2014-8480 (C, published 2014-11-10T11:55Z)
Description: value: The instruction decoder in arch/x86/kvm/emulate.c in the KVM subsystem in the Linux kernel before 3.18-rc2 lacks intended decoder-table flags for certain RIP-relative instructions, which allows guest OS users to cause a denial of service (NULL pointer dereference and host OS crash) via a crafted application.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-399 \u2014 Resource Management Errors
Weaknesses in this category are related to improper management of system resources.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/kvm/emulate.c
Commit message: KVM: x86: PREFETCH and HINT_NOP should have SrcMem flag

The decode phase of the x86 emulator assumes that every instruction with the
ModRM flag, and which can be used with RIP-relative addressing, has either
SrcMem or DstMem.  This is not the case for several instructions - prefetch,
hint-nop and clflush.

Adding SrcMem|NoAccess for prefetch and hint-nop and SrcMem for clflush.

This fixes CVE-2014-8480.

Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


Vulnerable code:
	I(0, em_clflush), N, N, N,
	N, D(ImplicitOps | ModRM), N, N,
	D(ImplicitOps | ModRM), N, N, N, N, N, N, D(ImplicitOps | ModRM),

Fixed code:
	I(SrcMem | ByteOp, em_clflush), N, N, N,
	N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
	D(ImplicitOps | ModRM | SrcMem | NoAccess),
	N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),
CVE-2016-5243 (C, published 2016-06-27T10:59Z)
Description: value: The tipc_nl_compat_link_dump function in net/tipc/netlink_compat.c in the Linux kernel through 4.6.3 does not properly copy a certain string, which allows local users to obtain sensitive information from kernel stack memory by reading a Netlink message.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/torvalds/linux
Files changed:
net/tipc/netlink_compat.c
Commit message: tipc: fix an infoleak in tipc_nl_compat_link_dump

link_info.str is a char array of size 60. Memory after the NULL
byte is not initialized. Sending the whole object out can cause
a leak.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
	strcpy(link_info.str, nla_data(link[TIPC_NLA_LINK_NAME]));

Fixed code:
	nla_strlcpy(link_info.str, nla_data(link[TIPC_NLA_LINK_NAME]),
		    TIPC_MAX_LINK_NAME);
CVE-2013-3224 (C, published 2013-04-22T11:41Z)
Description: value: The bt_sock_recvmsg function in net/bluetooth/af_bluetooth.c in the Linux kernel before 3.9-rc7 does not properly initialize a certain length variable, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/torvalds/linux
Files changed:
net/bluetooth/af_bluetooth.c
Commit message: Bluetooth: fix possible info leak in bt_sock_recvmsg()

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
	msg->msg_namelen = 0;


Fixed code:
	msg->msg_namelen = 0;
CVE-2017-12154 (C, published 2017-09-26T05:29Z)
Description: value: The prepare_vmcs02 function in arch/x86/kvm/vmx.c in the Linux kernel through 4.13.3 does not ensure that the "CR8-load exiting" and "CR8-store exiting" L0 vmcs02 controls exist in cases where L1 omits the "use TPR shadow" vmcs12 control, which allows KVM L2 guest OS users to obtain read and write access to the hardware CR8 register.
Severity: LOW (CVSS v3 base score: 7.1)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/kvm/vmx.c
Commit message: kvm: nVMX: Don't allow L2 to access the hardware CR8

If L1 does not specify the "use TPR shadow" VM-execution control in
vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store
exiting" VM-execution controls in vmcs02. Failure to do so will give
the L2 VM unrestricted read/write access to the hardware CR8.

This fixes CVE-2017-12154.

Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


Vulnerable code:

Fixed code:
	} else {
#ifdef CONFIG_X86_64
		exec_control |= CPU_BASED_CR8_LOAD_EXITING |
				CPU_BASED_CR8_STORE_EXITING;
#endif