linux-toradex.git/include, branch v2.6.16.14

[PATCH] i386: fix broken FP exception handling

2006-05-01T19:03:44+00:00

The FXSAVE information leak patch introduced a bug in FP exception
handling: it clears FP exceptions only when there are already
none outstanding.  Mikael Pettersson reported that causes problems
with the Erlang runtime and has tested this fix.

Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Acked-by: Mikael Pettersson 
Signed-off-by: Greg Kroah-Hartman

[PATCH] MIPS: R2 build fixes for gcc < 3.4.

2006-05-01T19:03:44+00:00

Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

[PATCH] MIPS: Use "R" constraint for cache_op.

2006-05-01T19:03:44+00:00

Gcc might emit an absolute address for the the "m" constraint which
gas unfortunately does not permit.

Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

[PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case

2006-05-01T19:03:44+00:00

Proposed fix for ptep_get_and_clear_full PAE bug.  Pte_clear had the same bug,
so use the same fix for both.  Turns out pmd_clear had it as well, but pgds
are not affected.

The problem is rather intricate.  Page table entries in PAE mode are 64-bits
wide, but the only atomic 8-byte write operation available in 32-bit mode is
cmpxchg8b, which is expensive (at least on P4), and thus avoided.  But it can
happen that the processor may prefetch entries into the TLB in the middle of an
operation which clears a page table entry.  So one must always clear the P-bit
in the low word of the page table entry first when clearing it.

Since the sequence *ptep = __pte(0) leaves the order of the write dependent on
the compiler, it must be coded explicitly as a clear of the low word followed
by a clear of the high word.  Further, there must be a write memory barrier
here to enforce proper ordering by the compiler (and, in the future, by the
processor as well).

On > 4GB memory machines, the implementation of pte_clear for PAE was clearly
deficient, as it could leave virtual mappings of physical memory above 4GB
aliased to memory below 4GB in the TLB.  The implementation of
ptep_get_and_clear_full has a similar bug, although not nearly as likely to
occur, since the mappings being cleared are in the process of being destroyed,
and should never be dereferenced again.

But, as luck would have it, it is possible to trigger bugs even without ever
dereferencing these bogus TLB mappings, even if the clear is followed fairly
soon after with a TLB flush or invalidation.  The problem is that memory above
4GB may now be aliased into the first 4GB of memory, and in fact, may hit a
region of memory with non-memory semantics.  These regions include AGP and PCI
space.  As such, these memory regions are not cached by the processor.  This
introduces the bug.

The processor can speculate memory operations, including memory writes, as long
as they are committed with the proper ordering.  Speculating a memory write to
a linear address that has a bogus TLB mapping is possible.  Normally, the
speculation is harmless.  But for cached memory, it does leave the falsely
speculated cacheline unmodified, but in a dirty state.  This cache line will be
eventually written back.  If this cacheline happens to intersect a region of
memory that is not protected by the cache coherency protocol, it can corrupt
data in I/O memory, which is generally a very bad thing to do, and can cause
total system failure or just plain undefined behavior.

These bugs are extremely unlikely, but the severity is of such magnitude, and
the fix so simple that I think fixing them immediately is justified.  Also,
they are nearly impossible to debug.

Signed-off-by: Zachary Amsden 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Simplify proc/devices and fix early termination regression

2006-05-01T19:03:43+00:00

Repair /proc/devices early-termination regression.

2.6.16 broke /proc/devices.  An application often gets an
EOF before the end of data is reached, if that application
uses a series of short read(2)s to access the data.  I have
used read buffers of varying sizes with varying degrees
of unsuccess (larger sizes get further into the data than
smaller sizes, following a simple pattern).  It appears
that the only safe way to get the data is to use a single
read buffer larger than all the data in /proc/devices.

The following example demonstates the problem:

    # dd if=/proc/devices bs=1
    Character devices:
      1 mem
    27+0 records in
    27+0 records out

This patch is a backport of the fix recently accepted to
Linus's tree:

    commit 68eef3b4791572ecb70249c7fb145bb3742dd899
    [PATCH] Simplify proc/devices and fix early termination regression

It replaces the complex, state-machine algorithm introduced
in 2.6.16 with a simple algorithm, modeled on the implementation
of /proc/interrupts.

[akpm@osdl.org: cleanups, simplifications]

Signed-off-by: Joe Korty 
Signed-off-by: Greg Kroah-Hartman

[PATCH] for_each_possible_cpu

2006-05-01T19:03:42+00:00

Backport for_each_possible_cpu() into 2.6.16.  Fixes the alpha build, and any
future occurrences.

Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056)

2006-04-19T05:54:44+00:00

AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending.  This means the value leak through context
switches and allow processes to observe some x87 instruction state of
other processes.

This was actually documented by AMD, but nobody recognized it as being
different from Intel before.

The fix first adds an optimization: instead of unconditionally calling
FNCLEX after each FXSAVE test if ES is pending and skip it when not
needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP.

This means other processes always will only see a constant value defined
by the kernel in their FP state.

I took some pain to make sure to chose a variable that's already in L1
during context switch to make the overhead of this low.

Also alternative() is used to patch away the new code on CPUs who don't
need it.

Patch for both i386/x86-64.

The problem was discovered originally by Jan Beulich. Richard Brunner
provided the basic code for the workarounds, with contribution from Jan.

This is CVE-2006-1056

Cc: richard.brunner@amd.com
Cc: jbeulich@novell.com
Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix buddy list race that could lead to page lru list corruptions

2006-04-17T20:16:05+00:00

Rohit found an obscure bug causing buddy list corruption.

page_is_buddy is using a non-atomic test (PagePrivate && page_count == 0)
to determine whether or not a free page's buddy is itself free and in the
buddy lists.

Each of the conjuncts may be true at different times due to unrelated
conditions, so the non-atomic page_is_buddy test may find each conjunct to
be true even if they were not both true at the same time (ie. the page was
not on the buddy lists).

Signed-off-by: Martin Bligh 
Signed-off-by: Rohit Seth 
Signed-off-by: Nick Piggin 
Signed-off-by: KAMEZAWA Hiroyuki 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

[PATCH] m32r: Fix cpu_possible_map and cpu_present_map initialization for SMP kernel

2006-04-17T20:16:05+00:00

This patch fixes a boot problem of the m32r SMP kernel 2.6.16-rc1-mm3 or
later.

In this patch, cpu_possible_map is statically initialized, and cpu_present_map
is also copied from cpu_possible_map in smp_prepare_cpus(), because the m32r
architecture has not supported CPU hotplug yet.

Signed-off-by: Hayato Fujiwara 
Signed-off-by: Hirokazu Takata 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] m32r: security fix of {get, put}_user macros

2006-04-17T20:16:04+00:00

Update {get,put}_user macros for m32r kernel.
- Modify get_user to use __get_user_asm macro, instead of __get_user_x macro.
- Remove arch/m32r/lib/{get,put}user.S.
- Some cosmetic updates.

I would like to thank NIIBE Yutaka for his reporting about the m32r kernel's
security problem in {get,put}_user macros.

There were no address checking for user space access in {get,put}_user macros.
 ;-)

Signed-off-by: Hirokazu Takata 
Cc: NIIBE Yutaka 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman