| 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
| ||
|
Message-ID: <e04d66f60711141031waeb9f1bu34a8fa4cadd5d6c3@mail.gmail.com> Date: Wed, 14 Nov 2007 18:31:15 +0000 From: "Robert Bragg" <robert@...bynine.org> To: "Andrew Morton" <akpm@...ux-foundation.org> Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: [PATCH] mm: Don't allow ioremapping of ranges larger than vmalloc space When running with a 16M IOREMAP_MAX_ORDER (on armv7) we found that the vmlist search routine in __get_vm_area_node can mistakenly allow a driver to ioremap a range larger than vmalloc space. If at the time of the ioremap all existing vmlist areas sit below the determined alignment then the search routine continues past all entries and exits the for loop - straight into the found: label - without ever testing for integer wrapping or that the requested size fits. We were seeing a driver successfully ioremap 128M of flash even though there was only 120M of vmalloc space. From that point the system was left with the remainder of the first 16M of space to vmalloc/ioremap within. Signed-off-by: Robert Bragg <robert@...bynine.org> --- diff --git a/mm/vmalloc.c b/mm/vmalloc.c index af77e17..06a7f3a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -216,6 +216,10 @@ static struct vm_struct *__get_vm_area_node if (addr > end - size) goto out; } + if ((size + addr) < addr) + goto out; + if (addr > end - size) + goto out; found: area->next = *p; - 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