linux-toradex.git, branch v3.12.51

Linux 3.12.51

2015-11-23T13:04:07+00:00

x86/mm/hotplug: Modify PGD entry when removing memory

2015-11-18T12:42:46+00:00

commit 9661d5bcd058fe15b4138a00d96bd36516134543 upstream.

When hot-adding/removing memory, sync_global_pgds() is called
for synchronizing PGD to PGD entries of all processes MM.  But
when hot-removing memory, sync_global_pgds() does not work
correctly.

At first, sync_global_pgds() checks whether target PGD is none
or not.  And if PGD is none, the PGD is skipped.  But when
hot-removing memory, PGD may be none since PGD may be cleared by
free_pud_table().  So when sync_global_pgds() is called after
hot-removing memory, sync_global_pgds() should not skip PGD even
if the PGD is none.  And sync_global_pgds() must clear PGD
entries of all processes MM.

Currently sync_global_pgds() does not clear PGD entries of all
processes MM when hot-removing memory.  So when hot adding
memory which is same memory range as removed memory after
hot-removing memory, following call traces are shown:

 kernel BUG at arch/x86/mm/init_64.c:206!
 ...
 [] kernel_physical_mapping_init+0x1b2/0x1d2
 [] init_memory_mapping+0x1d4/0x380
 [] arch_add_memory+0x3d/0xd0
 [] add_memory+0xb9/0x1b0
 [] acpi_memory_device_add+0x1af/0x28e
 [] acpi_bus_device_attach+0x8c/0xf0
 [] acpi_ns_walk_namespace+0xc8/0x17f
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] acpi_walk_namespace+0x95/0xc5
 [] acpi_bus_scan+0x9a/0xc2
 [] acpi_scan_bus_device_check+0x8b/0x12e
 [] acpi_scan_device_check+0x13/0x15
 [] acpi_os_execute_deferred+0x25/0x32
 [] process_one_work+0x17b/0x460
 [] worker_thread+0x11b/0x400
 [] ? rescuer_thread+0x400/0x400
 [] kthread+0xcf/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140

This patch clears PGD entries of all processes MM when
sync_global_pgds() is called after hot-removing memory

Signed-off-by: Yasuaki Ishimatsu 
Acked-by: Toshi Kani 
Signed-off-by: Andrew Morton 
Cc: Tang Chen 
Cc: Gu Zheng 
Cc: Zhang Yanfei 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Cc: Vlastimil Babka 
Signed-off-by: Jiri Slaby

x86/mm/hotplug: Pass sync_global_pgds() a correct argument in remove_pagetable()

2015-11-18T12:42:37+00:00

commit 5255e0a79fcc0ff47b387af92bd9ef5729b1b859 upstream.

When hot-adding memory after hot-removing memory, following call
traces are shown:

  kernel BUG at arch/x86/mm/init_64.c:206!
  ...
 [] kernel_physical_mapping_init+0x1b2/0x1d2
 [] init_memory_mapping+0x1d4/0x380
 [] arch_add_memory+0x3d/0xd0
 [] add_memory+0xb9/0x1b0
 [] acpi_memory_device_add+0x1af/0x28e
 [] acpi_bus_device_attach+0x8c/0xf0
 [] acpi_ns_walk_namespace+0xc8/0x17f
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] acpi_walk_namespace+0x95/0xc5
 [] acpi_bus_scan+0x9a/0xc2
 [] acpi_scan_bus_device_check+0x8b/0x12e
 [] acpi_scan_device_check+0x13/0x15
 [] acpi_os_execute_deferred+0x25/0x32
 [] process_one_work+0x17b/0x460
 [] worker_thread+0x11b/0x400
 [] ? rescuer_thread+0x400/0x400
 [] kthread+0xcf/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140

The patch-set fixes the issue.

This patch (of 2):

remove_pagetable() gets start argument and passes the argument
to sync_global_pgds().  In this case, the argument must not be
modified.  If the argument is modified and passed to
sync_global_pgds(), sync_global_pgds() does not correctly
synchronize PGD to PGD entries of all processes MM since
synchronized range of memory [start, end] is wrong.

Unfortunately the start argument is modified in
remove_pagetable().  So this patch fixes the issue.

Signed-off-by: Yasuaki Ishimatsu 
Acked-by: Toshi Kani 
Signed-off-by: Andrew Morton 
Cc: Tang Chen 
Cc: Gu Zheng 
Cc: Zhang Yanfei 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Cc: Vlastimil Babka 
Signed-off-by: Jiri Slaby

ipv6: addrconf: validate new MTU before applying it

2015-11-18T11:45:11+00:00

commit 77751427a1ff25b27d47a4c36b12c3c8667855ac upstream.

Currently we don't check if the new MTU is valid or not and this allows
one to configure a smaller than minimum allowed by RFCs or even bigger
than interface own MTU, which is a problem as it may lead to packet
drops.

If you have a daemon like NetworkManager running, this may be exploited
by remote attackers by forging RA packets with an invalid MTU, possibly
leading to a DoS. (NetworkManager currently only validates for values
too small, but not for too big ones.)

The fix is just to make sure the new value is valid. That is, between
IPV6_MIN_MTU and interface's MTU.

Note that similar check is already performed at
ndisc_router_discovery(), for when kernel itself parses the RA.

Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

KVM: x86: Use new is_noncanonical_address in _linearize

2015-11-18T11:43:22+00:00

commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 upstream.

Replace the current canonical address check with the new function which is
identical.

Signed-off-by: Nadav Amit 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: Fix far-jump to non-canonical check

2015-11-18T10:28:01+00:00

commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.

Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far
jumps") introduced a bug that caused the fix to be incomplete.  Due to
incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
not trigger #GP.  As we know, this imposes a security problem.

In addition, the condition for two warnings was incorrect.

Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715
Reported-by: Dan Carpenter 
Signed-off-by: Nadav Amit 
[Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: svm: unconditionally intercept #DB

2015-11-18T10:08:02+00:00

commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.

This is needed to avoid the possibility that the guest triggers
an infinite stream of #DB exceptions (CVE-2015-8104).

VMX is not affected: because it does not save DR6 in the VMCS,
it already intercepts #DB unconditionally.

Reported-by: Jan Beulich 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: work around infinite loop in microcode when #AC is delivered

2015-11-18T10:08:01+00:00

commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.

It was found that a guest can DoS a host by triggering an infinite
stream of "alignment check" (#AC) exceptions.  This causes the
microcode to enter an infinite loop where the core never receives
another interrupt.  The host kernel panics pretty quickly due to the
effects (CVE-2015-5307).

Signed-off-by: Eric Northup 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: Defining missing x86 vectors

2015-11-18T10:08:00+00:00

commit c9cdd085bb75226879fd468b88e2e7eb467325b7 upstream.

Defining XE, XM and VE vector numbers.

Signed-off-by: Nadav Amit 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

2015-11-18T09:27:26+00:00

commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 upstream.

The following sequence of commands:

    i=`keyctl add user a a @s`
    keyctl request2 keyring foo bar @t
    keyctl unlink $i @s

tries to invoke an upcall to instantiate a keyring if one doesn't already
exist by that name within the user's keyring set.  However, if the upcall
fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
other error code.  When the key is garbage collected, the key destroy
function is called unconditionally and keyring_destroy() uses list_empty()
on keyring->type_data.link - which is in a union with reject_error.
Subsequently, the kernel tries to unlink the keyring from the keyring names
list - which oopses like this:

	BUG: unable to handle kernel paging request at 00000000ffffff8a
	IP: [] keyring_destroy+0x3d/0x88
	...
	Workqueue: events key_garbage_collector
	...
	RIP: 0010:[] keyring_destroy+0x3d/0x88
	RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
	RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
	RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
	RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
	R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
	R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
	...
	CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
	...
	Call Trace:
	 [] key_gc_unused_keys.constprop.1+0x5d/0x10f
	 [] key_garbage_collector+0x1fa/0x351
	 [] process_one_work+0x28e/0x547
	 [] worker_thread+0x26e/0x361
	 [] ? rescuer_thread+0x2a8/0x2a8
	 [] kthread+0xf3/0xfb
	 [] ? kthread_create_on_node+0x1c2/0x1c2
	 [] ret_from_fork+0x3f/0x70
	 [] ? kthread_create_on_node+0x1c2/0x1c2

Note the value in RAX.  This is a 32-bit representation of -ENOKEY.

The solution is to only call ->destroy() if the key was successfully
instantiated.

Reported-by: Dmitry Vyukov 
Signed-off-by: David Howells 
Tested-by: Dmitry Vyukov 
Signed-off-by: Jiri Slaby