netdev - Re: attempted oversize allocations in tcp

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-prev] [day] [month] [year] [list]

Message-Id: <20111228.140633.884619516495494384.davem@davemloft.net>
Date:	Wed, 28 Dec 2011 14:06:33 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	davej@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: attempted oversize allocations in tcp_recvmsg.

From: Dave Jones <davej@...hat.com>
Date: Wed, 28 Dec 2011 13:44:17 -0500

> I got this trace from the page allocator while fuzzing sys_recvfrom
 ...
> 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?

I would say that it is dma_pin_iovec_pages()'s job to validate things, since the
fact that it does this kmalloc() whose size is some function of the given length
is it's business.

> 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 ?

That's fine, we'll just try to process the recvmsg() without using the
DMA memcpy offloading.  It's exactly the same as if we took the else
branch here.

Anyways, please report this to the DMA layer maintainer.

Thanks.

--
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