CVE-2011-1090: Medium severity linux kernel vulnerability

"The "badpage()" page allocator sanity check was reported recently (call chain as follows):

badpage+0x69/0x91 freehotcoldpage+0x81/0x144 skbreleasedata+0x5f/0x98 kfreeskb+0x11/0x1a tcpack+0x6a3/0x1868 tcprcvestablished+0x7a6/0x8b9 tcpv4dorcv+0x2a/0x2fa tcpv4rcv+0x9a2/0x9f6 dotimer+0x2df/0x52c iplocaldeliver+0x19d/0x263 iprcv+0x539/0x57c netifreceiveskb+0x470/0x49f :virtionet:virtnetpoll+0x46b/0x5c5 netrxaction+0xac/0x1b3 dosoftirq+0x89/0x133 callsoftirq+0x1c/0x28 dosoftirq+0x2c/0x7d doIRQ+0xec/0xf5 defaultidle+0x0/0x50 retfromintr+0x0/0xa defaultidle+0x29/0x50 cpuidle+0x95/0xb8 startkernel+0x220/0x225 sinittext+0x22f/0x236

It occurs because an skb with a fraglist was freed from the tcp retransmit queue when it was acked, but a page on that fraglist had PGSlab set (indicating it was allocated from the Slab allocator (which means the free path above can't safely free it via putpage.

We tracked this back to an nfsv4 setacl operation, in which the nfs code attempted to fill convert the passed in buffer to an array of pages in nfs4procsetacl, which gets used by the skb->frags list in xssendpages. nfs4procsetacl just converts each page in the buffer to a page struct via virttopage, but the vfs allocates the buffer via kmalloc, meaning the PGslab bit is set. We can't create a buffer with kmalloc and free it later in the tcp ack path with putpage, so we need to either:

1) ensure that when we create the list of pages, no page struct has PGSlab set

or

2) not use a page list to send this data

Given that these buffers can be multiple pages and arbitrarily sized, I think (1) is the right way to go. I've written the below patch to allocate a page from the buddy allocator directly and copy the data over to it. This ensures that we have a putpage free-able page for every entry that winds up on an skb frag list, so it can be safely freed when the frame is acked. We do a put page on each entry after the rpccallsync call so as to drop our own reference count to the page, leaving only the ref count taken by tcpsendpages. This way the data will be properly freed when the ack comes in

Successfully tested by myself to solve the above oops.

Note, as this is the result of a setacl operation that exceeded a page of data, I think this amounts to a local DOS triggerable by an uprivlidged user, so I'm CCing security on this as well."

Upstream commit: http://git.kernel.org/linus/e9e3d724e2145f5039b423c290ce2b2c3d8f94bc

Introduced in 4b580ee3 v2.6.13-rc4