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+FuTSfw+-6Xb_0xchM5E6vCMSsyiSvSYF3MbuE25pEt07RRbw@mail.gmail.com>
Date:	Wed, 29 Jul 2015 02:05:33 -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 Mon, Jul 27, 2015 at 6:35 PM, Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
> Hi Johann,
>
> On Tue, Jul 21, 2015 at 6:51 PM, Willem de Bruijn <willemb@...gle.com> wrote:
>> 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.
> I know it's summer (and thus vacation-time), but did you already have
> a chance to look into this?

Martin, to return to your initial statement that PPPoE PADI packets can
have a zero payload: the PPPoE RFC states that PADI packets "MUST
contain exactly one TAG of TAG_TYPE Service-Name, indicating the
service the Host is requesting, and any number of other TAG types."
(RFC 2516, 5.1). Is the observed behavior (no payload) perhaps
incorrect?

Even if it is, if this is breaking established userspace expectations,
we should look into it. Ethernet specifies a minimum payload size of
46 on the wire, but perhaps that is handled with padding, so that
0 length should be valid within the stack. Also, there may be other
valid uses of 0 length payload on top of link layers that are not Ethernet.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ