linux-toradex.git, branch v2.6.27.37

Linux 2.6.27.37

2009-10-12T18:40:01+00:00

time: catch xtime_nsec underflows and fix them

2009-10-12T18:33:23+00:00

commit 6c9bacb41c10ba84ff68f238e234d96f35fb64f7 upstream.

Impact: fix time warp bug

Alex Shi, along with Yanmin Zhang have been noticing occasional time
inconsistencies recently. Through their great diagnosis, they found that
the xtime_nsec value used in update_wall_time was occasionally going
negative. After looking through the code for awhile, I realized we have
the possibility for an underflow when three conditions are met in
update_wall_time():

  1) We have accumulated a second's worth of nanoseconds, so we
     incremented xtime.tv_sec and appropriately decrement xtime_nsec.
     (This doesn't cause xtime_nsec to go negative, but it can cause it
      to be small).

  2) The remaining offset value is large, but just slightly less then
     cycle_interval.

  3) clocksource_adjust() is speeding up the clock, causing a
     corrective amount (compensating for the increase in the multiplier
     being multiplied against the unaccumulated offset value) to be
     subtracted from xtime_nsec.

This can cause xtime_nsec to underflow.

Unfortunately, since we notify the NTP subsystem via second_overflow()
whenever we accumulate a full second, and this effects the error
accumulation that has already occured, we cannot simply revert the
accumulated second from xtime nor move the second accumulation to after
the clocksource_adjust call without a change in behavior.

This leaves us with (at least) two options:

1) Simply return from clocksource_adjust() without making a change if we
   notice the adjustment would cause xtime_nsec to go negative.

This would work, but I'm concerned that if a large adjustment was needed
(due to the error being large), it may be possible to get stuck with an
ever increasing error that becomes too large to correct (since it may
always force xtime_nsec negative). This may just be paranoia on my part.

2) Catch xtime_nsec if it is negative, then add back the amount its
   negative to both xtime_nsec and the error.

This second method is consistent with how we've handled earlier rounding
issues, and also has the benefit that the error being added is always in
the oposite direction also always equal or smaller then the correction
being applied. So the risk of a corner case where things get out of
control is lessened.

This patch fixes bug 11970, as tested by Yanmin Zhang
http://bugzilla.kernel.org/show_bug.cgi?id=11970

Reported-by: alex.shi@intel.com
Signed-off-by: John Stultz 
Acked-by: Yanmin Zhang 
Tested-by: Yanmin Zhang 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

hpwdt.c: Add new HP BMC controller.

2009-10-12T18:33:22+00:00

commit d8100c3abfd32986a8820ce4e614b0223a2d22a9 upstream.

Add the PCI-ID for the upcoming new BMC controller for HP hardware.

Signed-off-by: Thomas Mingarelli 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Disallow hypercalls for guest callers in rings > 0 [CVE-2009-3290]

2009-10-12T18:33:20+00:00

[ backport to 2.6.27 by Chuck Ebbert  ]

commit 07708c4af1346ab1521b26a202f438366b7bcffd upstream.

So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.

To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.

Signed-off-by: Jan Kiszka 
Signed-off-by: Avi Kivity 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: Increase MIN_GAP to include randomized stack

2009-10-12T18:33:15+00:00

[ trivial backport to 2.6.27: Chuck Ebbert  ]

commit 80938332d8cf652f6b16e0788cf0ca136befe0b5 upstream.

Currently we are not including randomized stack size when calculating
mmap_base address in arch_pick_mmap_layout for topdown case. This might
cause that mmap_base starts in the stack reserved area because stack is
randomized by 1GB for 64b (8MB for 32b) and the minimum gap is 128MB.

If the stack really grows down to mmap_base then we can get silent mmap
region overwrite by the stack values.

Let's include maximum stack randomization size into MIN_GAP which is
used as the low bound for the gap in mmap.

Signed-off-by: Michal Hocko 
LKML-Reference: <1252400515-6866-1-git-send-email-mhocko@suse.cz>
Acked-by: Jiri Kosina 
Signed-off-by: H. Peter Anvin 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Prevent lower dentry from going negative during unlink (CVE-2009-2908)

2009-10-12T18:33:06+00:00

commit 9c2d2056647790c5034d722bd24e9d913ebca73c upstream.

When calling vfs_unlink() on the lower dentry, d_delete() turns the
dentry into a negative dentry when the d_count is 1.  This eventually
caused a NULL pointer deref when a read() or write() was done and the
negative dentry's d_inode was dereferenced in
ecryptfs_read_update_atime() or ecryptfs_getxattr().

Placing mutt's tmpdir in an eCryptfs mount is what initially triggered
the oops and I was able to reproduce it with the following sequence:

open("/tmp/upper/foo", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 3
link("/tmp/upper/foo", "/tmp/upper/bar") = 0
unlink("/tmp/upper/foo")                = 0
open("/tmp/upper/bar", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 4
unlink("/tmp/upper/bar")                = 0
write(4, "eCryptfs test\n"..., 14 
+++ killed by SIGKILL +++

https://bugs.launchpad.net/ecryptfs/+bug/387073

Reported-by: Loïc Minier 
Cc: Serge Hallyn 
Cc: Dave Kleikamp 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Tyler Hicks 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: Don't leak 64-bit kernel register values to 32-bit processes

2009-10-12T18:32:58+00:00

commit 24e35800cdc4350fc34e2bed37b608a9e13ab3b6 upstream

x86: Don't leak 64-bit kernel register values to 32-bit processes

While 32-bit processes can't directly access R8...R15, they can
gain access to these registers by temporarily switching themselves
into 64-bit mode.

Therefore, registers not preserved anyway by called C functions
(i.e. R8...R11) must be cleared prior to returning to user mode.

Signed-off-by: Jan Beulich 
LKML-Reference: <4AC34D73020000780001744A@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86-64: slightly stream-line 32-bit syscall entry code

2009-10-12T18:32:51+00:00

commit 295286a89107c353b9677bc604361c537fd6a1c0 upstream

x86-64: slightly stream-line 32-bit syscall entry code

[ required for following patch to apply properly ]

Avoid updating registers or memory twice as well as needlessly loading
or copying registers.

Signed-off-by: Jan Beulich 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

net: Fix wrong sizeof

2009-10-12T18:32:48+00:00

commit b607bd900051efc3308c4edc65dd98b34b230021 upstream.

Which is why I have always preferred sizeof(struct foo) over
sizeof(var).

Signed-off-by: Jean Delvare 
Acked-by: Randy Dunlap 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Linux 2.6.27.36

2009-10-05T15:19:01+00:00