commit 8521cde0ae1b66dd68228ac674d9f0609767dc0a Author: Greg Kroah-Hartman Date: Mon Oct 12 11:40:01 2009 -0700 Linux 2.6.27.37 commit 3ce4d0a0f7184d5fe17747841f628adac60ed262 Author: john stultz Date: Mon Dec 1 18:34:41 2008 -0800 time: catch xtime_nsec underflows and fix them 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 commit d15ab7d95452998ef87158a6202a8351d52fdd51 Author: Thomas Mingarelli Date: Tue Mar 3 00:17:16 2009 +0000 hpwdt.c: Add new HP BMC controller. 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 commit c905930150d0952c4ce008553b377492bcbd29d7 Author: Jan Kiszka Date: Wed Oct 7 17:40:32 2009 -0400 KVM: x86: Disallow hypercalls for guest callers in rings > 0 [CVE-2009-3290] [ 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 commit 2578cf95969936c372db29ee2bbc21c9b6a299aa Author: Michal Hocko Date: Wed Oct 7 17:38:24 2009 -0400 x86: Increase MIN_GAP to include randomized stack [ 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 commit da40cf167d517e0f2cdd79a0d0590482a8532585 Author: Tyler Hicks Date: Wed Oct 7 17:35:46 2009 -0400 eCryptfs: Prevent lower dentry from going negative during unlink (CVE-2009-2908) 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 commit 329e7f58ae607c2dccc7e523e56c60d373dc6e4b Author: Jan Beulich Date: Wed Oct 7 17:34:09 2009 -0400 x86: Don't leak 64-bit kernel register values to 32-bit processes 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 commit 0a778acf2aeddbc18ed5eab1fbff10bbbe785e16 Author: Jan Beulich Date: Wed Oct 7 17:33:08 2009 -0400 x86-64: slightly stream-line 32-bit syscall entry code 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 commit 0ee31b391059a1e8d46df0afe59b345f425f1224 Author: Jean Delvare Date: Fri Oct 2 09:55:19 2009 -0700 net: Fix wrong sizeof 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