aboutsummaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorPaul Mackerras <paulus@samba.org>2008-04-12 15:20:59 +1000
committerPaul Mackerras <paulus@samba.org>2008-04-15 21:22:17 +1000
commitd9024df02ffe74d723d97d552f86de3b34beb8cc (patch)
tree6e753db66f4404526d6c22a41a3a050dc156db72 /kernel
parent300613e523d53f346f8ff0256921e289da39ed7b (diff)
downloadkernel_samsung_smdk4412-d9024df02ffe74d723d97d552f86de3b34beb8cc.zip
kernel_samsung_smdk4412-d9024df02ffe74d723d97d552f86de3b34beb8cc.tar.gz
kernel_samsung_smdk4412-d9024df02ffe74d723d97d552f86de3b34beb8cc.tar.bz2
[LMB] Restructure allocation loops to avoid unsigned underflow
There is a potential bug in __lmb_alloc_base where we subtract `size' from the base address of a reserved region without checking whether the subtraction could wrap around and produce a very large unsigned value. In fact it probably isn't possible to hit the bug in practice since it would only occur in the situation where we can't satisfy the allocation request and there is a reserved region starting at 0. This fixes the potential bug by breaking out of the loop when we get to the point where the base of the reserved region is less than the size requested. This also restructures the loop to be a bit easier to follow. The same logic got copied into lmb_alloc_nid_unreserved, so this makes a similar change there. Here the bug is more likely to be hit because the outer loop (in lmb_alloc_nid) goes through the memory regions in increasing order rather than decreasing order as __lmb_alloc_base does, and we are therefore more likely to hit the case where we are testing against a reserved region with a base address of 0. Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions