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

Message-ID: <CAHmME9q-tr72=R79-++JAyHv=FM5_mh=MZ-Q3x0kJoY8o9gLsw@mail.gmail.com>
Date:   Sun, 13 May 2018 15:24:47 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Md. Islam" <mislam4@...t.edu>
Cc:     Netdev <netdev@...r.kernel.org>, brouer@...hat.com,
        sbrivio@...hat.com
Subject: Re: safe skb resetting after decapsulation and encapsulation

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.

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