linux-stable.git/arch, branch v3.2.79

s390/mm: four page table levels vs. fork

2016-04-01T00:54:37+00:00

commit 3446c13b268af86391d06611327006b059b8bab1 upstream.

The fork of a process with four page table levels is broken since
git commit 6252d702c5311ce9 "[S390] dynamic page tables."

All new mm contexts are created with three page table levels and
an asce limit of 4TB. If the parent has four levels dup_mmap will
add vmas to the new context which are outside of the asce limit.
The subsequent call to copy_page_range will walk the three level
page table structure of the new process with non-zero pgd and pud
indexes. This leads to memory clobbers as the pgd_index *and* the
pud_index is added to the mm->pgd pointer without a pgd_deref
in between.

The init_new_context() function is selecting the number of page
table levels for a new context. The function is used by mm_init()
which in turn is called by dup_mm() and mm_alloc(). These two are
used by fork() and exec(). The init_new_context() function can
distinguish the two cases by looking at mm->context.asce_limit,
for fork() the mm struct has been copied and the number of page
table levels may not change. For exec() the mm_alloc() function
set the new mm structure to zero, in this case a three-level page
table is created as the temporary stack space is located at
STACK_TOP_MAX = 4TB.

This fixes CVE-2016-2143.

Reported-by: Marcin Kościelnicki 
Reviewed-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
[bwh: Backported to 3.2:
 - 31-bit s390 is still supported so keep the #ifdef CONFIG_64BIT conditions
 - Split page table locks are not implemented for PMDs so don't call
   pgtable_pmd_page_{ctor,dtor}()
 - PMDs are not accounted so don't call mm_inc_nr_pmds()
 - Adjust context]
Signed-off-by: Ben Hutchings

MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'

2016-04-01T00:54:37+00:00

commit e723e3f7f9591b79e8c56b3d7c5a204a9c571b55 upstream.

Avoid sending a partially initialised `siginfo_t' structure along SIGFPE
signals issued from `do_ov' and `do_trap_or_bp', leading to information
leaking from the kernel stack.

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Ralf Baechle 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

PM / sleep / x86: Fix crash on graph trace through x86 suspend

2016-04-01T00:54:36+00:00

commit 92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 upstream.

Pause/unpause graph tracing around do_suspend_lowlevel as it has
inconsistent call/return info after it jumps to the wakeup vector.
The graph trace buffer will otherwise become misaligned and
may eventually crash and hang on suspend.

To reproduce the issue and test the fix:
Run a function_graph trace over suspend/resume and set the graph
function to suspend_devices_and_enter. This consistently hangs the
system without this fix.

Signed-off-by: Todd Brandt 
Signed-off-by: Rafael J. Wysocki 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache()

2016-04-01T00:54:33+00:00

commit a82eee7424525e34e98d821dd059ce14560a1e35 upstream.

Data corruption issues were observed in tests which initiated
a system crash/reset while accessing BTT devices.  This problem
is reproducible.

The BTT driver calls pmem_rw_bytes() to update data in pmem
devices.  This interface calls __copy_user_nocache(), which
uses non-temporal stores so that the stores to pmem are
persistent.

__copy_user_nocache() uses non-temporal stores when a request
size is 8 bytes or larger (and is aligned by 8 bytes).  The
BTT driver updates the BTT map table, which entry size is
4 bytes.  Therefore, updates to the map table entries remain
cached, and are not written to pmem after a crash.

Change __copy_user_nocache() to use non-temporal store when
a request size is 4 bytes.  The change extends the current
byte-copy path for a less-than-8-bytes request, and does not
add any overhead to the regular path.

Reported-and-tested-by: Micah Parrish 
Reported-and-tested-by: Brian Boylston 
Signed-off-by: Toshi Kani 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dan Williams 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Ross Zwisler 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: Vishal Verma 
Cc: linux-nvdimm@lists.01.org
Link: http://lkml.kernel.org/r/1455225857-12039-3-git-send-email-toshi.kani@hpe.com
[ Small readability edits. ]
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.2: aadjust filename, context]
Signed-off-by: Ben Hutchings

x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable

2016-04-01T00:54:33+00:00

commit ee9737c924706aaa72c2ead93e3ad5644681dc1c upstream.

Add comments to __copy_user_nocache() to clarify its procedures
and alignment requirements.

Also change numeric branch target labels to named local labels.

No code changed:

 arch/x86/lib/copy_user_64.o:

    text    data     bss     dec     hex filename
    1239       0       0    1239     4d7 copy_user_64.o.before
    1239       0       0    1239     4d7 copy_user_64.o.after

 md5:
    58bed94c2db98c1ca9a2d46d0680aaae  copy_user_64.o.before.asm
    58bed94c2db98c1ca9a2d46d0680aaae  copy_user_64.o.after.asm

Signed-off-by: Toshi Kani 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: brian.boylston@hpe.com
Cc: dan.j.williams@intel.com
Cc: linux-nvdimm@lists.01.org
Cc: micah.parrish@hpe.com
Cc: ross.zwisler@linux.intel.com
Cc: vishal.l.verma@intel.com
Link: http://lkml.kernel.org/r/1455225857-12039-2-git-send-email-toshi.kani@hpe.com
[ Small readability edits and added object file comparison. ]
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.2: aadjust filename, context]
Signed-off-by: Ben Hutchings

x86, extable: Remove open-coded exception table entries in arch/x86/lib/copy_user_nocache_64.S

2016-04-01T00:54:33+00:00

commit 0d8559feafbc9dc5a2c17ba42aea7de824b18308 upstream.

Remove open-coded exception table entries in arch/x86/lib/copy_user_nocache_64.S,
and replace them with _ASM_EXTABLE() macros; this will allow us to
change the format and type of the exception table entries.

Signed-off-by: H. Peter Anvin 
Cc: David Daney 
Link: http://lkml.kernel.org/r/CA%2B55aFyijf43qSu3N9nWHEBwaGbb7T2Oq9A=9EyR=Jtyqfq_cQ@mail.gmail.com
Signed-off-by: Ben Hutchings

ARM: 8519/1: ICST: try other dividends than 1

2016-02-27T14:28:48+00:00

commit e972c37459c813190461dabfeaac228e00aae259 upstream.

Since the dawn of time the ICST code has only supported divide
by one or hang in an eternal loop. Luckily we were always dividing
by one because the reference frequency for the systems using
the ICSTs is 24MHz and the [min,max] values for the PLL input
if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop
will always terminate immediately without assigning any divisor
for the reference frequency.

But for the code to make sense, let's insert the missing i++

Reported-by: David Binderman 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 8517/1: ICST: avoid arithmetic overflow in icst_hz()

2016-02-27T14:28:48+00:00

commit 5070fb14a0154f075c8b418e5bc58a620ae85a45 upstream.

When trying to set the ICST 307 clock to 25174000 Hz I ran into
this arithmetic error: the icst_hz_to_vco() correctly figure out
DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
25174000 Hz out of the VCO. (I replicated the icst_hz() function
in a spreadsheet to verify this.)

However, when I called icst_hz() on these VCO settings it would
instead return 4122709 Hz. This causes an error in the common
clock driver for ICST as the common clock framework will call
.round_rate() on the clock which will utilize icst_hz_to_vco()
followed by icst_hz() suggesting the erroneous frequency, and
then the clock gets set to this.

The error did not manifest in the old clock framework since
this high frequency was only used by the CLCD, which calls
clk_set_rate() without first calling clk_round_rate() and since
the old clock framework would not call clk_round_rate() before
setting the frequency, the correct values propagated into
the VCO.

After some experimenting I figured out that it was due to a simple
arithmetic overflow: the divisor for 24Mhz reference frequency
as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
in bit 32 overflows and is lost.

But introducing an explicit 64-by-32 bit do_div() and casting
the divisor into (u64) we get the right frequency back, and the
right frequency gets set.

Tested on the ARM Versatile.

Cc: linux-clk@vger.kernel.org
Cc: Pawel Moll 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

x86/mm/pat: Avoid truncation when converting cpa->numpages to address

2016-02-27T14:28:45+00:00

commit 742563777e8da62197d6cb4b99f4027f59454735 upstream.

There are a couple of nasty truncation bugs lurking in the pageattr
code that can be triggered when mapping EFI regions, e.g. when we pass
a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting
left by PAGE_SHIFT will truncate the resultant address to 32-bits.

Viorel-Cătălin managed to trigger this bug on his Dell machine that
provides a ~5GB EFI region which requires 1236992 pages to be mapped.
When calling populate_pud() the end of the region gets calculated
incorrectly in the following buggy expression,

  end = start + (cpa->numpages << PAGE_SHIFT);

And only 188416 pages are mapped. Next, populate_pud() gets invoked
for a second time because of the loop in __change_page_attr_set_clr(),
only this time no pages get mapped because shifting the remaining
number of pages (1048576) by PAGE_SHIFT is zero. At which point the
loop in __change_page_attr_set_clr() spins forever because we fail to
map progress.

Hitting this bug depends very much on the virtual address we pick to
map the large region at and how many pages we map on the initial run
through the loop. This explains why this issue was only recently hit
with the introduction of commit

  a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap
   entries bottom-up at runtime, instead of top-down")

It's interesting to note that safe uses of cpa->numpages do exist in
the pageattr code. If instead of shifting ->numpages we multiply by
PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and
so the result is unsigned long.

To avoid surprises when users try to convert very large cpa->numpages
values to addresses, change the data type from 'int' to 'unsigned
long', thereby making it suitable for shifting by PAGE_SHIFT without
any type casting.

The alternative would be to make liberal use of casting, but that is
far more likely to cause problems in the future when someone adds more
code and fails to cast properly; this bug was difficult enough to
track down in the first place.

Reported-and-tested-by: Viorel-Cătălin Răpițeanu 
Acked-by: Borislav Petkov 
Cc: Sai Praneeth Prakhya 
Signed-off-by: Matt Fleming 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110131
Link: http://lkml.kernel.org/r/1454067370-10374-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings

KVM: vmx: fix MPX detection

2016-02-27T14:28:41+00:00

commit 920c837785699bcc48f4a729ba9ee3492f620b95 upstream.

kvm_x86_ops is still NULL at this point.  Since kvm_init_msr_list
cannot fail, it is safe to initialize it before the call.

Fixes: 93c4adc7afedf9b0ec190066d45b6d67db5270da
Reported-by: Fengguang Wu 
Tested-by: Jet Chen 
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Cc: Brad Spengler 
[bwh: Dependency of "KVM: x86: expose MSR_TSC_AUX to userspace",
 applied in 3.2.77]
Signed-off-by: Ben Hutchings