netdev - Re: [PATCH] AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2)

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

Message-ID: <4AE8B114.6050504@gmail.com>
Date:	Wed, 28 Oct 2009 22:01:08 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Neil Horman <nhorman@...driver.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] AF_RAW: Augment raw_send_hdrinc to expand skb to fit
 iphdr->ihl (v2)

Neil Horman a écrit :
> 
>> I believe we should drop the request, since padding it is not what was expected by user.
> 
> Yeah, I had a feeling.  Ok, version 2, this time drop the invalid frame and
> report it to user space, instead of expanding it:
> 
> 
>     Augment raw_send_hdrinc to correct for incorrect ip header length values
>     
>     A series of oopses was reported to me recently.  Apparently when using AF_RAW
>     sockets to send data to peers that were reachable via ipsec encapsulation,
>     people could panic or BUG halt their systems.
>     
>     I've tracked the problem down to user space sending an invalid ip header over an
>     AF_RAW socket with IP_HDRINCL set to 1.
>     
>     Basically what happens is that userspace sends down an ip frame that includes
>     only the header (no data), but sets the ip header ihl value to a large number,
>     one that is larger than the total amount of data passed to the sendmsg call.  In
>     raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
>     that was passed in, but assume the data is all valid.  Later during ipsec
>     encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
>     to provide headroom for the ipsec headers.  During this operation, the
>     skb->transport_header is repointed to a spot computed by
>     skb->network_header + the ip header length (ihl).  Since so little data was
>     passed in relative to the value of ihl provided by the raw socket, we point
>     transport header to an unknown location, resulting in various crashes.
>     
>     This fix for this is pretty straightforward, simply validate the value of of
>     iph->ihl when sending over a raw socket.  If (iph->ihl*4U) > user data buffer
>     size, drop the frame and return -EINVAL.  I just confirmed this fixes the
>     reported crashes.
>     
>     Signed-off-by: Neil Horman <nhorman@...driver.com>

Acked-by: Eric Dumazet <eric.dumazet@...il.com>

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