netdev - Re: safe skb resetting after decapsulation and encapsulation

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]

Date:   Mon, 14 May 2018 17:06:37 -0400
From:   "Md. Islam" <mislam4@...t.edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        sbrivio@...hat.com
Subject: Re: safe skb resetting after decapsulation and encapsulation

On Sun, May 13, 2018 at 9:24 AM, Jason A. Donenfeld <Jason@...c4.com> wrote:
> On Sat, May 12, 2018 at 4:07 AM, Md. Islam <mislam4@...t.edu> wrote:
>> I'm not an expert on this, but it looks about right.
>
> Really? Even zeroing between headers_start and headers_end? With the
> latest RHEL 7.5 kernel's i40e driver, doing this results in a crash in
> kfree. It's possible redhat is putting something silly within
> header_start and header_end, and so zeroing it is bad, but I suspect
> that instead blanket zeroing it like that might actually be incorrect.

I had similar issue where I was trying to convert an xdp_buff to
sk_buff. It was crashing in kfree. I figured it was due to skb_shinfo
being empty in my case. skb_skb_shinfo is located at the tail room.
http://vger.kernel.org/~davem/skb_data.html

>
>> look at build_skb() or __build_skb(). It shows the fields that needs to be set
>
> These just kmalloc a new skb, with most fields set to zero. The ones
> it modifies are the ones I'm modifying anyway when messing with the
> data the skb contains. Doesn't look like there's much to help there.
>
>
> I wrote the original post wondering precisely -- which specifically of
> 1-14 are incorrect, and is there anything specific missing from there.