netdev - Re: Getting at the UDP headers from ->data

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]

Date:	Mon, 11 Apr 2016 17:18:40 -0400
From:	Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Willem de Bruijn <willemb@...gle.com>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: Getting at the UDP headers from ->data_ready()

On Mon, Apr 11, 2016 at 5:04 PM, David Howells <dhowells@...hat.com> wrote:
> Hi Willem,
>
> With regards to:
>
>     commit 4d0fc73ebe94ac984a187f21fbf4f3a1ac846f5a
>     Author: Willem de Bruijn <willemb@...gle.com>
>     Date:   Thu Apr 7 11:44:59 2016 -0400
>
>     rxrpc: do not pull udp headers on receive
>
>     Commit e6afc8ace6dd modified the udp receive path by pulling the udp
>     header before queuing an skbuff onto the receive queue.
>
> Does that mean that I can no longer access the UDP header via udp_hdr(skb)
> from with the ->data_ready() handler?
>
> I'm guessing that's not actually the case since ip_hdr(skb) seems to work - or
> is that something I shouldn't be using since the part of the buffer containing
> the IP header might've been discarded?

The network and transport header pointers are still valid. Commit e6afc8ace6dd
only  changes where skb->data points to. It does not discard the data between
skb->head and skb->data. This rxrpc follow-up patch fixes some offset
arithmetic to the payload, which is computed relative to skb->data.

There are other uses of ip_hdr and udp_hdr in udp_recvmsg and similar
recvmsg handlers for other protocols. For instance, in the source address
processing for recvfrom ("if (sin) { .. }")