From: "Jan Lübbe" <jluebbe@debian.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Scot Doyle <lkml@scotdoyle.com>,
Stephen Hemminger <shemminger@vyatta.com>,
Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>,
netdev@vger.kernel.org
Subject: Re: Kernel panic when using bridge
Date: Tue, 12 Apr 2011 16:19:28 +0200 [thread overview]
Message-ID: <1302617968.30934.34.camel@polaris.local> (raw)
In-Reply-To: <1302614145.3233.47.camel@edumazet-laptop>
On Tue, 2011-04-12 at 15:15 +0200, Eric Dumazet wrote:
> Le mardi 12 avril 2011 à 15:02 +0200, Jan Lübbe a écrit :
> > Here you check dopt->optlen, which certainly should be 40 at most. The
> > calculation of dopt->optlen wasn't changed by my patch, though.
>
> Check again the thread Jan.
>
> Scot is using a tool (IP Stack Checker's tcpsic) to forge random tcp
> packets.
> Maybe your patch is fine but requires a change in a previous function,
> to make sure we deny some crazy packet before generating an ip_options
> with more than 40 bytes, in an icmp_send() reply.
One thing which could expose a problem is that it now will timestamp the
packet in the last 'slot', too. (which it didn't before)
In general, there is not a lot of error-checking in the options stuff.
> I took a look at this ip_options stuff and must say its really hard to
> even _read_ the code. Understanding it might need several days or a new
> brain ?
It took me some days do even figure out how it is supposed to fit
together...
> I cannot Ack or Nack your patch, I must admit it. Isnt it frightening?
David Miller already declared this code as 'officially terrible'...
Your patch should catch those forged packets before more harmful things
can go wrong, but even before my patch, i think forged packets could
cause trouble...
Regards,
Jan
next prev parent reply other threads:[~2011-04-12 14:19 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 1:20 Kernel panic when using bridge Scot Doyle
2011-04-08 13:49 ` Sebastian Nickel
2011-04-08 14:57 ` Scot Doyle
2011-04-08 19:12 ` Pallai Roland
2011-04-08 19:17 ` Stephen Hemminger
2011-04-09 4:51 ` Scot Doyle
2011-04-09 7:19 ` Hiroaki SHIMODA
2011-04-11 23:48 ` Scot Doyle
2011-04-12 1:31 ` Stephen Hemminger
2011-04-12 3:47 ` Scot Doyle
2011-04-12 4:09 ` Eric Dumazet
2011-04-12 4:22 ` Eric Dumazet
2011-04-12 5:17 ` Scot Doyle
2011-04-12 5:51 ` Eric Dumazet
2011-04-12 7:02 ` Scot Doyle
2011-04-12 7:31 ` Eric Dumazet
2011-04-12 8:39 ` [PATCH] inetpeer: reduce stack usage Eric Dumazet
2011-04-12 14:51 ` Hiroaki SHIMODA
2011-04-12 14:55 ` Eric Dumazet
2011-04-12 20:58 ` David Miller
2011-04-12 11:49 ` Kernel panic when using bridge Eric Dumazet
2011-04-12 13:02 ` Jan Lübbe
2011-04-12 13:15 ` Eric Dumazet
2011-04-12 14:19 ` Jan Lübbe [this message]
2011-04-12 14:49 ` Eric Dumazet
2011-04-12 15:13 ` Jan Lübbe
2011-04-12 16:14 ` Eric Dumazet
2011-04-12 16:20 ` Stephen Hemminger
2011-04-12 16:35 ` Eric Dumazet
2011-04-12 16:45 ` Bandan Das
2011-04-12 16:54 ` Eric Dumazet
2011-04-12 17:18 ` [PATCH] bridge: reset IPCB in br_parse_ip_options Eric Dumazet
2011-04-12 20:39 ` David Miller
2011-04-12 23:55 ` Scot Doyle
2011-04-13 4:12 ` Scot Doyle
2011-04-13 15:10 ` Scot Doyle
2011-04-13 15:24 ` Stephen Hemminger
2011-04-13 15:54 ` Scot Doyle
2011-04-13 15:28 ` Eric Dumazet
2011-04-13 21:48 ` David Miller
2011-04-14 0:03 ` Stephen Hemminger
2011-04-14 0:05 ` David Miller
2011-04-14 0:08 ` Stephen Hemminger
2011-04-14 2:31 ` Eric Dumazet
2011-04-14 2:54 ` Stephen Hemminger
2011-04-14 3:03 ` [PATCH] ip: ip_options_compile() resilient to NULL skb route Eric Dumazet
2011-04-14 3:30 ` Hiroaki SHIMODA
2011-04-14 3:37 ` Eric Dumazet
2011-04-14 4:15 ` Hiroaki SHIMODA
2011-04-14 13:34 ` Scot Doyle
2011-04-14 15:55 ` [PATCH v2] " Eric Dumazet
2011-04-14 22:02 ` Scot Doyle
2011-04-14 22:04 ` David Miller
2011-04-14 23:20 ` Hiroaki SHIMODA
2011-04-15 6:26 ` David Miller
2011-04-12 16:32 ` Kernel panic when using bridge Bandan Das
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=1302617968.30934.34.camel@polaris.local \
--to=jluebbe@debian.org \
--cc=eric.dumazet@gmail.com \
--cc=lkml@scotdoyle.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=shimoda.hiroaki@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).