lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Feb 2009 07:54:48 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Justin Chen <jchen@...st41.cup.hp.com>
Cc:	linux-arch@...r.kernel.org, bjorn.helgaas@...com,
	justin.chen@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] bitops: Change bitmap index from int to unsigned
 long

On Tue, 2009-02-24 at 20:41 -0800, Justin Chen wrote:
> his patch is to change the bitmap index in the bitops from "int" to
> "unsigned long".
> 
> In many bitops implementations, the bitmap index is a signed int.  If
> the caller passes a large unsigned integer and we interpret it as
> being negative, we compute an address outside the bitmap.  This can
> cause memory corruption or other errors.
> 
> The issue that triggered me to do this change is the routine
> mark_bootmem_node() while we ran on an ia64 box with large memory.  As
> long as the EFI maps the available memory chunk at the physical
> address 0x200000000000 (or above), the routine mark_bootmem_node()
> will get the start PFN>=0x80000000.  While it calls the __free() with
> this sidx=0x80000000 (bit31 set), the bitops (test_and_clear_bit) will
> treat this idx as a negative number since it accepts it as an "int".
> It turns out the memory outside the bitmap will be corrupted.
> 
> Following 15 patches will change all the bitmap index "nr" in all
> bitops from "int" to "unsigned long".
> 
> The patch is based on 2.6.29-rc6
> 
> Please comment -

unsigned int wasn't large enough?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ