netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@linux.intel.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	David Miller <davem@davemloft.net>
Cc: Heikki Hannikainen <hessu@hes.iki.fi>,
	Network Development <netdev@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: Sending short raw packets using sendmsg() broke
Date: Wed, 02 Mar 2016 00:00:22 +0000	[thread overview]
Message-ID: <1456876822.7064.36.camel@linux.intel.com> (raw)
In-Reply-To: <CAF=yD-+m09_KS9+SyMZsTES5iLPyVE10F0u6pt4tVeYcDk8=PQ@mail.gmail.com>

> More thorough validation of the header contents is not necessarily
> hard. The following validates the address, including optional
> repeaters.
> 
>   static bool ax25_validate_hard_header(const char *ll_header,
>                                        unsigned short len)
>   {
>          ax25_digi digi;
> 
>          return !ax25_addr_parse(ll_header, len, NULL, NULL, &digi,
> NULL, NULL);
>   }

This also breaks because there is a KISS header byte on an AX.25
transmission and it is valid to send a KISS control frame via
SOCK_PACKET but it cannot be generated by other protocols.

Basically everything hitting an AX.25 port is either a zero byte
followed by an AX.25 frame, or a KISS frame the first of which is non
zero and which is used to set parameters on the radio side.

The AX.25 device level drivers are simply written to be robust if
thrown partial frames.

The other thing that concerns me about this added logic in general is
that you are also breaking test tools that want to deliberately send
corrupt frames to certain classes of interface. I'm not sure how big an
issue that is given we always for example padded ethernet frames
properly, but the more validation we do for a privileged interface the
more we prevent applications for testing network behaviour from being
able to run on Linux. Possibly there should be a CAP_SYS_RAWIO test but
making it impossible is a bad step.

Alan

  reply	other threads:[~2016-03-02  0:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-25 19:36 Sending short raw packets using sendmsg() broke Heikki Hannikainen
2016-02-25 20:26 ` David Miller
2016-02-26 14:44   ` Alan Cox
2016-02-26 17:33     ` Willem de Bruijn
2016-02-26 17:46       ` David Miller
2016-02-27 23:02         ` Willem de Bruijn
2016-03-02  0:00           ` Alan Cox [this message]
2016-03-03 16:40             ` Willem de Bruijn
2016-03-03 16:43               ` Willem de Bruijn
2016-03-04 15:54                 ` Alan Cox
2016-03-04 16:33                   ` Willem de Bruijn
2016-03-04 20:52                     ` Willem de Bruijn
2016-03-01 23:34       ` Alan Cox
2016-02-26 17:34     ` David Miller
2016-02-25 20:49 ` Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1456876822.7064.36.camel@linux.intel.com \
    --to=alan@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=hessu@hes.iki.fi \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).