From: William Allen Simpson <william.allen.simpson@gmail.com>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: netdev <netdev@vger.kernel.org>,
Patrick McHardy <kaber@trash.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data
Date: Tue, 19 Jan 2010 04:17:25 -0500 [thread overview]
Message-ID: <4B5578A5.50705@gmail.com> (raw)
In-Reply-To: <4B54CDE5.3070100@simon.arlott.org.uk>
Simon Arlott wrote:
> The check for data only needs to apply where the packet length
> could be increased by adding the MSS option. (The MSS option
> itself applies to the sender's maximum receive size which is
> not relevant to any data in its own packet.)
>
> This moves the check for (header size != packet size) to after
> attempting to modify an existing MSS option. Another check is
> needed before looking through the header to ensure it doesn't
> claim to be larger than the packet size.
>
What's the path from tcp_v[4,6]_rcv() to these tests?
1) Header larger than the packet is already tested in about 5 places,
and my patch "tcp: harmonize tcp_vx_rcv header length assumptions"
tries to get them all down to just *one* test.
2) There certainly *can* be data on SYN. That code is already in
2.6.33....
> The ERROR level printk() is also removed as it can be triggered
> by remote hosts and is not useful:
> [4941777.937417] xt_TCPMSS: bad length (40 bytes)
> [4941782.409724] xt_TCPMSS: bad length (40 bytes)
> [4941790.762332] xt_TCPMSS: bad length (40 bytes)
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
> ---
> net/netfilter/xt_TCPMSS.c | 21 +++++++++++----------
> 1 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/net/netfilter/xt_TCPMSS.c b/net/netfilter/xt_TCPMSS.c
> index eda64c1..76f92bf 100644
> --- a/net/netfilter/xt_TCPMSS.c
> +++ b/net/netfilter/xt_TCPMSS.c
> @@ -60,17 +60,9 @@ tcpmss_mangle_packet(struct sk_buff *skb,
> tcplen = skb->len - tcphoff;
> tcph = (struct tcphdr *)(skb_network_header(skb) + tcphoff);
>
> - /* Since it passed flags test in tcp match, we know it is is
> - not a fragment, and has data >= tcp header length. SYN
> - packets should not contain data: if they did, then we risk
> - running over MTU, sending Frag Needed and breaking things
> - badly. --RR */
> - if (tcplen != tcph->doff*4) {
> - if (net_ratelimit())
> - printk(KERN_ERR "xt_TCPMSS: bad length (%u bytes)\n",
> - skb->len);
> + /* Header cannot be larger than the packet */
> + if (tcplen < tcph->doff*4)
> return -1;
> - }
>
> if (info->mss == XT_TCPMSS_CLAMP_PMTU) {
> if (dst_mtu(skb_dst(skb)) <= minlen) {
> @@ -115,6 +107,15 @@ tcpmss_mangle_packet(struct sk_buff *skb,
> }
> }
>
> + /* Since it passed flags test in tcp match, we know it is
> + not a fragment, and has data >= tcp header length. SYN
> + packets should not contain data: if they did, then we risk
> + running over MTU, sending Frag Needed and breaking things
> + badly. --RR
> + */
> + if (tcplen > tcph->doff*4)
> + return -1;
> +
> /*
> * MSS Option not found ?! add it..
> */
next prev parent reply other threads:[~2010-01-19 9:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 21:08 [PATCH] xt_TCPMSS: SYN packets are allowed to contain data Simon Arlott
2010-01-19 9:17 ` William Allen Simpson [this message]
2010-01-19 9:30 ` Patrick McHardy
2010-01-19 12:43 ` Simon Arlott
2010-01-19 12:53 ` Patrick McHardy
2010-01-19 12:50 ` Simon Arlott
2010-01-19 15:44 ` William Allen Simpson
2010-01-20 12:59 ` Simon Arlott
2010-01-20 21:21 ` Simon Arlott
2010-01-20 21:39 ` Jan Engelhardt
2010-01-20 21:41 ` Jan Engelhardt
2010-01-20 21:51 ` Simon Arlott
2010-01-20 22:22 ` Amos Jeffries
2010-01-20 23:14 ` Patrick McHardy
2010-01-21 12:47 ` Simon Arlott
2010-01-21 12:58 ` Jan Engelhardt
2010-01-21 13:02 ` Patrick McHardy
2010-01-21 20:13 ` Simon Arlott
2010-02-02 14:34 ` Patrick McHardy
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=4B5578A5.50705@gmail.com \
--to=william.allen.simpson@gmail.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.