linux.git/arch/x86/include, branch v3.18.72

x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

2017-09-02T05:05:46+00:00

commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.

The x86 version of insb/insw/insl uses an inline assembly that does
not have the target buffer listed as an output. This can confuse
the compiler, leading it to think that a subsequent access of the
buffer is uninitialized:

  drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
  drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c: In function 'sb1000_rx':
  drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]

I tried to mark the exact input buffer as an output here, but couldn't
figure it out. As suggested by Linus, marking all memory as clobbered
however is good enough too. For the outs operations, I also add the
memory clobber, to force the input to be written to local variables.
This is probably already guaranteed by the "asm volatile", but it can't
hurt to do this for symmetry.

Suggested-by: Linus Torvalds 
Signed-off-by: Arnd Bergmann 
Acked-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
Link: https://lkml.org/lkml/2017/7/12/605
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Plug race between mapping and ELF header setup

2017-04-22T05:14:57+00:00

commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 upstream.

The vsyscall32 sysctl can racy against a concurrent fork when it switches
from disabled to enabled:

    arch_setup_additional_pages()
	if (vdso32_enabled)
           --> No mapping
                                        sysctl.vsysscall32()
                                          --> vdso32_enabled = true
    create_elf_tables()
      ARCH_DLINFO_IA32
        if (vdso32_enabled) {
           --> Add VDSO entry with NULL pointer

Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
the newly forked process or not.

Signed-off-by: Thomas Gleixner 
Acked-by: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Mathias Krause 
Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Fix potential infoleak in older kernels

2017-04-18T05:55:45+00:00

commit dc1555e670c373bfa4ca2e1e2f839d5fe2b4501a upstream.

Not upstream as it is not needed there.

So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.

THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception
handler.

It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.


Signed-off-by: Greg Kroah-Hartman

x86/init: Fix cr4_init_shadow() on CR4-less machines

2016-12-23T14:41:34+00:00

[ Upstream commit e1bfc11c5a6f40222a698a818dc269113245820e ]

cr4_init_shadow() will panic on 486-like machines without CR4.  Fix
it using __read_cr4_safe().

Reported-by: david@saggiorato.net
Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

fix minor infoleak in get_user_ex()

2016-10-06T02:40:20+00:00

[ Upstream commit 1c109fabbd51863475cd12ac206bdd249aee35af ]

get_user_ex(x, ptr) should zero x on failure.  It's not a lot of a leak
(at most we are leaking uninitialized 64bit value off the kernel stack,
and in a fairly constrained situation, at that), but the fix is trivial,
so...

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro 
[ This sat in different branch from the uaccess fixes since mid-August ]
Signed-off-by: Linus Torvalds 

Signed-off-by: Sasha Levin

x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

2016-06-06T23:11:12+00:00

[ Upstream commit 8abb850a03a3a8b11a0e92949e5b99d9cc178e35 ]

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu 
Tested-by: Sander Eikelenboom 
Cc: Tony Luck 
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk 
Cc: David Vrabel 
Cc: Bjorn Helgaas 
Cc: Graeme Gregory 
Cc: Lv Zheng 
Link: http://lkml.kernel.org/r/1421720467-7709-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

mm: fix huge zero page accounting in smaps report

2016-06-03T15:30:36+00:00

[ Upstream commit c164e038eee805147e95789dddb88ae3b3aca11c ]

As a small zero page, huge zero page should not be accounted in smaps
report as normal page.

For small pages we rely on vm_normal_page() to filter out zero page, but
vm_normal_page() is not designed to handle pmds.  We only get here due
hackish cast pmd to pte in smaps_pte_range() -- pte and pmd format is not
necessary compatible on each and every architecture.

Let's add separate codepath to handle pmds.  follow_trans_huge_pmd() will
detect huge zero page for us.

We would need pmd_dirty() helper to do this properly.  The patch adds it
to THP-enabled architectures which don't yet have one.

[akpm@linux-foundation.org: use do_div to fix 32-bit build]
Signed-off-by: "Kirill A. Shutemov" 
Reported-by: Fengguang Wu 
Tested-by: Fengwei Yin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

Signed-off-by: Sasha Levin

x86/mm/xen: Suppress hugetlbfs in PV guests

2016-05-10T16:20:19+00:00

[ Upstream commit 103f6112f253017d7062cd74d17f4a514ed4485c ]

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode: 0000 [#1] SMP
  ...
  RIP: e030:[]  [] remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: stable@vger.kernel.org
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()

2016-04-18T12:49:35+00:00

[ Upstream commit 7834c10313fb823e538f2772be78edcdeed2e6e3 ]

Since 4.4, I've been able to trigger this occasionally:

===============================
[ INFO: suspicious RCU usage. ]
4.5.0-rc7-think+ #3 Not tainted
Cc: Andi Kleen 
Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
Signed-off-by: Thomas Gleixner 

-------------------------------
./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/3/0.

stack backtrace:
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
 ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
Call Trace:
   [] dump_stack+0x67/0x9d
 [] lockdep_rcu_suspicious+0xe6/0x100
 [] do_trace_write_msr+0x127/0x1a0
 [] native_apic_msr_eoi_write+0x23/0x30
 [] smp_trace_call_function_interrupt+0x38/0x360
 [] trace_call_function_interrupt+0x90/0xa0
   [] ? cpuidle_enter_state+0x1b4/0x520

Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
tells the RCU susbstems to end the extended quiescent state, so that the
following trace call in ack_APIC_irq() works correctly.

Suggested-by: Andi Kleen 
Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
Signed-off-by: Dave Jones 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

perf/x86/intel: Add definition for PT PMI bit

2016-04-18T12:49:24+00:00

[ Upstream commit 5690ae28e472d25e330ad0c637a5cea3fc39fb32 ]

This patch adds a definition for GLOBAL_OVFL_STATUS bit 55
which is used with the Processor Trace (PT) feature.

Signed-off-by: Stephane Eranian 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: adrian.hunter@intel.com
Cc: kan.liang@intel.com
Cc: namhyung@kernel.org
Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin