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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 28 Dec 2011 13:44:17 -0500
From:	Dave Jones <davej@...hat.com>
To:	netdev@...r.kernel.org
Subject: attempted oversize allocations in tcp_recvmsg.

I got this trace from the page allocator while fuzzing sys_recvfrom

WARNING: at mm/page_alloc.c:2089 __alloc_pages_nodemask+0x39b/0xa50()
Hardware name: X8DTN
Modules linked in: nfnetlink binfmt_misc ip6_queue can_raw can_bcm rfcomm ipt_ULOG cmtp kernelcapi bnep sctp libcrc32c ip_queue dccp_ipv6 dccp_ipv4 >
Pid: 26212, comm: trinity Not tainted 3.1.6-1.fc16.x86_64.debug #1
Call Trace:
 [<ffffffff8107940f>] warn_slowpath_common+0x7f/0xc0
 [<ffffffff8107946a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff811461db>] __alloc_pages_nodemask+0x39b/0xa50
 [<ffffffff8117efa3>] alloc_pages_current+0xa3/0x110
 [<ffffffff81141604>] __get_free_pages+0x14/0x50
 [<ffffffff8118b57f>] kmalloc_order_trace+0x3f/0x170
 [<ffffffff8118bc08>] __kmalloc+0x268/0x290
 [<ffffffff8139a64d>] dma_pin_iovec_pages+0x9d/0x220
 [<ffffffff8157b7e7>] tcp_recvmsg+0x787/0xcb0
 [<ffffffff815a34cb>] inet_recvmsg+0x10b/0x180
 [<ffffffff81511ead>] sock_recvmsg+0x11d/0x140
 [<ffffffff815159e1>] sys_recvfrom+0xf1/0x170
 [<ffffffff816698c2>] system_call_fastpath+0x16/0x1b
---[ end trace 9a0c4dd55e1dbe8a ]---


The code in tcp_recvmsg that passes down the enormous size has these checks..

                if (skb)
                        available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
                if ((available < target) &&
                    (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
                    !sysctl_tcp_low_latency &&
                    dma_find_channel(DMA_MEMCPY)) {
                        preempt_enable_no_resched();
                        tp->ucopy.pinned_list =
                                        dma_pin_iovec_pages(msg->msg_iov, len);
                } else {
                        preempt_enable_no_resched();
                }

I'm guessing there should be a (len < 65535) (or similar constant) in that check ?
Or should we be doing this even sooner in one of the earlier functions?

Also, when that dma_pin_iovec_pages fails, we still proceed through the rest of
tcp_recvmsg. Is that expected ? Or should it be doing a goto out; in that case ?

	Dave

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ