linux-toradex.git, branch v2.6.27.38

Linux 2.6.27.38

2009-10-22T07:22:46+00:00

Signed-off-by: Greg Kroah-Hartman

USB: digi_acceleport: Fix broken unthrottle.

2009-10-22T04:51:10+00:00

commit ba6b702f85a61561d329c4c11d3ed95604924f9a upstream.

This patch fixes a regression introduced in
39892da44b21b5362eb848ca424d73a25ccc488f.

Signed-off-by: Johan Hovold 
Acked-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

SCSI: Fix protection scsi_data_buffer leak

2009-10-22T04:51:10+00:00

commit b4c2554d40ceac130a8d062eaa8838ed22158c45 upstream.

We would leak a scsi_data_buffer if the free_list command was of the
protected variety.

Reported-by: Boaz Harrosh 
Signed-off-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

usb-serial: fix crash when sub-driver updates firmware

2009-10-22T04:51:09+00:00

commit 0a3c8549ea7e94d74a41096d42bc6cdf43d183bf upstream.

This patch (as1244) fixes a crash in usb-serial that occurs when a
sub-driver returns a positive value from its attach method, indicating
that new firmware was loaded and the device will disconnect and
reconnect.  The usb-serial core then skips the step of registering the
port devices; when the disconnect occurs, the attempt to unregister
the ports fails dramatically.

This problem shows up with Keyspan devices and it might affect others
as well.

When the attach method returns a positive value, the patch sets
num_ports to 0.  This tells usb_serial_disconnect() not to try
unregistering any of the ports; instead they are cleaned up by
destroy_serial().

Signed-off-by: Alan Stern 
Tested-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

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