kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes

Bruce Evans brde at optusnet.com.au
Tue Nov 22 18:54:06 UTC 2011


On Mon, 21 Nov 2011, Adam McDougall wrote:

>> Description:

> [Misformatted lines deleted]

>> Fix:
>
> Patch attached with submission follows:
>
> --- sys/kern/kern_malloc.c.orig	2011-11-21 12:19:25.712591472 -0500
> +++ sys/kern/kern_malloc.c	2011-11-21 17:25:11.831042640 -0500
> @@ -704,10 +704,10 @@
> 	 * Limit kmem virtual size to twice the physical memory.
> 	 * This allows for kmem map sparseness, but limits the size
> 	 * to something sane. Be careful to not overflow the 32bit
> -	 * ints while doing the check.
> +	 * ints while doing the check or the adjustment.
> 	 */
> 	if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count)
> -		vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE;
> +		vm_kmem_size = 2 * mem_size * PAGE_SIZE;
>
> #ifdef DEBUG_MEMGUARD
> 	tmp = memguard_fudge(vm_kmem_size, vm_kmem_size_max);

cnt.v_page_count should probably be spelled as mem_size in the check too.

The limit is still garbage for 32-bit systems.  32-bit systems can
easily have 2-4GB of physical memory.  i386 with PAE can have much
more.  Overflow can't occur in (2 * cnt.v_page_count * PAGE_SIZE)
since the original vm_kmem_size is limited to 4G-1 by u_long bogusly
being 32 bits on all supported 32-bit systems.  But the user can
misconfigure things so that the original vm_kmem_size is only slightly
less than 4G.  Then there cannot be that much kva.  But when there is
>= 2G physical, clamping kva to <= 2*physical has no effect.

VM_KMEM_SIZE_MAX or vm.kmem_size would have to be misconfigured for
vm_kmem_size to be impossibly large.  This means that the above code
usually has no effect on 32-bit systems.

Bruce


More information about the freebsd-bugs mailing list