IB/umem: Avoid sign problems when demoting npages to integer
authorRoland Dreier <rolandd@cisco.com>
Sat, 7 Jun 2008 04:38:37 +0000 (21:38 -0700)
committerRoland Dreier <rolandd@cisco.com>
Sat, 7 Jun 2008 04:38:37 +0000 (21:38 -0700)
commit8079ffa0e18baaf2940e52e0c118eef420a473a4
tree9593f8c324864bcb8514548d3ecab7cc1bf1cab7
parentaab2545fdd6641b76af0ae96456c4ca9d1e50dad
IB/umem: Avoid sign problems when demoting npages to integer

On a 64-bit architecture, if ib_umem_get() is called with a size value
that is so big that npages is negative when cast to int, then the
length of the page list passed to get_user_pages(), namely

min_t(int, npages, PAGE_SIZE / sizeof (struct page *))

will be negative, and get_user_pages() will immediately return 0 (at
least since 900cf086, "Be more robust about bad arguments in
get_user_pages()").  This leads to an infinite loop in ib_umem_get(),
since the code boils down to:

while (npages) {
ret = get_user_pages(...);
npages -= ret;
}

Fix this by taking the minimum as unsigned longs, so that the value of
npages is never truncated.

The impact of this bug isn't too severe, since the value of npages is
checked against RLIMIT_MEMLOCK, so a process would need to have an
astronomical limit or have CAP_IPC_LOCK to be able to trigger this,
and such a process could already cause lots of mischief.  But it does
let buggy userspace code cause a kernel lock-up; for example I hit
this with code that passes a negative value into a memory registartion
function where it is promoted to a huge u64 value.

Cc: <stable@kernel.org>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
drivers/infiniband/core/umem.c