9616ca7
9616ca7
# HG changeset patch
9616ca7
# User Tim Deegan <tim@xen.org>
9616ca7
# Date 1358426606 -3600
9616ca7
# Node ID 0db8dfa1a378df5a3ec10485164b57e8b3b3e573
9616ca7
# Parent  a064a93a1eadff8adc14b488c6beb4ccdc7931ae
9616ca7
x86/mm: Fix loop increment in paging_log_dirty_range()
9616ca7
9616ca7
In 23417:53ef1f35a0f8 (the fix for XSA-27 / CVE-2012-5511), the
9616ca7
loop variable gets incremented twice, so the loop only clears every
9616ca7
second page of the bitmap.  This might cause the tools to think that
9616ca7
pages are dirty when they are not.
9616ca7
9616ca7
Reported-by: Steven Noonan <snoonan@amazon.com>
9616ca7
Reported-by: Matt Wilson <msw@amazon.com>
9616ca7
Signed-off-by: Tim Deegan <tim@xen.org>
9616ca7
Acked-by: Ian Campbell <ian.campbell@citrix.com>
9616ca7
Committed-by: Jan Beulich <jbeulich@suse.com>
9616ca7
9616ca7
diff -r a064a93a1ead -r 0db8dfa1a378 xen/arch/x86/mm/paging.c
9616ca7
--- a/xen/arch/x86/mm/paging.c	Thu Jan 17 12:22:48 2013 +0000
9616ca7
+++ b/xen/arch/x86/mm/paging.c	Thu Jan 17 13:43:26 2013 +0100
9616ca7
@@ -534,7 +534,8 @@ int paging_log_dirty_range(struct domain
9616ca7
 
9616ca7
         size = ((nr + BITS_PER_LONG - 1) / BITS_PER_LONG) * sizeof (long);
9616ca7
         rv = 0;
9616ca7
-        for ( off = 0; !rv && off < size; off += sizeof zeroes )
9616ca7
+        off = 0;
9616ca7
+        while ( !rv && off < size )
9616ca7
         {
9616ca7
             int todo = min(size - off, (int) PAGE_SIZE);
9616ca7
             if ( copy_to_guest_offset(dirty_bitmap, off, zeroes, todo) )
9616ca7