netdev - Re: [PATCH] packet: Allow packets with only a header (but no payload)

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: <CA+FuTSctXr=2eC_-e793hvAPu=XyEhLeLoowH95tbOBx8CGj7g@mail.gmail.com>
Date:	Tue, 21 Jul 2015 12:51:04 -0400
From:	Willem de Bruijn <willemb@...gle.com>
To:	Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:	Network Development <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	David Miller <davem@...emloft.net>, johann.baudy@...-log.net
Subject: Re: [PATCH] packet: Allow packets with only a header (but no payload)

On Tue, Jul 21, 2015 at 12:38 PM, Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
> Hi Willem,
>
> On Tue, Jul 21, 2015 at 6:28 PM, Willem de Bruijn <willemb@...gle.com> wrote:
>> Interesting. 9c7077622dd9 only extended the check from tpacket_snd to
>> packet_snd to make the two paths equivalent. The existing check had the
>> ominous statement
>>
>>     /* net device doesn't like empty head */
> OK, I guess it's best to find out what the purpose of this comment is.
>
>> so allowing a header-only packet while correct in your case may not be
>> safe in some edge cases (specific device drivers?).
> I'm wondering how a good fix would look like (I can think of a few
> things, like renaming hard_header_len to something min_packet_size)?
> I am open for suggestions since I have zero knowledge about the inner
> workings of the packet framework.

I don't see a simple way of verifying the safety of allowing packets
without data short of a code audit, which would be huge, especially
when taking device driver logic into account. Perhaps someone
remembers why that statement was added and what edge case(s)
it refers to. I'm afraid that I don't. It was added in 69e3c75f4d54. I
added the author to this thread.

>> This was also discussed previously
>>
>>   http://www.spinics.net/lists/netdev/msg309677.html
>>
>> In any case, I don't think that reverting the patch and restoring the old
>> inconsistent state is a fix.
> I totally agree with you that it's a bad fix if this means that we
> could break other drivers.
> My primary goal was to fix PPPoE connections - I guess I should have
> simply added "RFC" to the subject.
>
>
> Regards,
> Martin
--
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