Re: [Security] TIPC security issues
On 10/28/2010 08:32 AM, Linus Torvalds wrote:
Heh. We apparently have _another_ iovec overflow in networking. This time rds. Reported by Thomas Pollet<thomas.pollet@xxxxxxxxx>: look at net/rds/rdma.c around line 490. It doesn't use the regular iovec code, instead it cooks its own, and has a few problems with overflow. It gathers the number of pages into an "unsigned int", and for each entry in its own rds_iovec it will check that the size is< UINT_MAX, and then generate the number of pages for that entry. With the whole "unaligned address adds one" logic, it means that each entry can get (UINT_MAX>> PAGE_SHIFT)+1 pages.
FWIW both the signed issue and not checking the iovec changed were correct in 2.6.36, and only added in ff87e97.
And how many entries can we have? Apparently that is capped to UINT_MAX too. So add all those up, and they can easily overflow the unsigned int page counter. So this time fixing verify_iovec() doesn't help, because rds just cooks its own, and this is using a totally different interface: it seems to hook into sendmsg, but it looks like it uses the ancillary data objects and passes in its own magical iovec rather than use any "normal" iovec thing. I don't know the code, I may be totally off.
Yes that's right, it's to map a memory region that will be the target of an RDMA operation. I don't know why struct rds_iovec was used instead of struct iovec, but I think we're stuck, since it's part of our socket API.
I'll send DaveM patches to fix those two immediately-identified problems today, and we'll take a good long look at the rest of the code for further issues.
Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html