netdev - Re: Why skb->data so far from skb->head after skb

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: <cef31c78be439a8f10af13c861a305684a0abd60.camel@redhat.com>
Date:   Fri, 11 Feb 2022 13:01:41 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Yi Li <lovelylich@...il.com>, netdev@...r.kernel.org
Subject: Re: Why skb->data so far from skb->head after skb_reserve?

On Fri, 2022-02-11 at 09:53 +0800, Yi Li wrote:
> Hi list,
> I am digging on skb layout when tcp send packets throught tcp/ip
> stack, but i am stuck on the skb->data now.
> I use the net-next branch, and the commit id
> 6cf7a1ac0fedad8a70c050ade8a27a2071638500, and i think this (problem?)
> is not relevant with specific commit id.
> 
> Firstly I just used systemtap to digging the routines, but when I
> found for every pkt, the data is far way from skb->head, i became
> curious.
> 
> After add some printk logs and analysis, I found the strange behavior
> as follows:
> 
> Let's only look at the tcp syn pkt when we do a tcp connection. I have
> added many logs , but for simply let's only see root cause, the
> following log:
> 
> static inline void skb_reserve(struct sk_buff *skb, int len)
> {
>     printk("%s:%d:  head=%p, data=%p, tail=%d, end=%d, len=%d,
> data_len=%d, transport_header=%d, nr_frags=%d\n",
>                     __func__, __LINE__, skb->head, skb->data,
> skb->tail, skb->end, skb->len, skb->data_len,
>                     skb->transport_header, skb_shinfo(skb)->nr_frags);
> skb->data += len;
>     printk("%s:%d:  head=%p, data=%p, tail=%d, end=%d, len=%d,
> data_len=%d, transport_header=%d, nr_frags=%d\n",
>                     __func__, __LINE__, skb->head, skb->data,
> skb->tail, skb->end, skb->len, skb->data_len,
>                     skb->transport_header, skb_shinfo(skb)->nr_frags);
> skb->tail += len;
> }
> 
> And I got the strange result:
> [  131.750170] skb_reserve:2453:  head=000000000cfe1b70,
> data=000000000cfe1b70, tail=0, end=704, len=0, data_len=0,
> transport_header=65535, nr_frags=0
> [  131.750173] skb_reserve:2457:  head=000000000cfe1b70,
> data=00000000bf8ffb2c, tail=0, end=704, len=0, data_len=0,
> transport_header=65535, nr_frags=0
> 
> Why the skb->data so far from skb->head, i can't understand. Could you
> kindly help me ?

printk by default hases the '%p' aguments, to avoid leaking kernel
information to user-space. You can modify that (Beware! only for debug
purpouse) booting the kernel with no_hash_pointers on the kernel
command line. Or you can cast the ptr to long. 

/P