Hi, I think we all agreed in the end that this is a possible, but highly implausible, scenario, and rather as a point of exploit than a functional bug. The solution is very simple, and described further down in this mail thread. I have not done anything to it yet, but you are welcome to contribute.
BR ///jon > -----Original Message----- > From: 张谦 [mailto:zhangqia...@360.cn] > Sent: Tuesday, 01 November, 2016 02:35 > To: Ben Hutchings <b...@decadent.org.uk>; Jon Maloy > <jon.ma...@ericsson.com>; Ying Xue <ying.x...@gmail.com> > Cc: netdev@vger.kernel.org; Eric Dumazet <eduma...@google.com> > Subject: Re: [PATCH net] tipc: Guard against tiny MTU in tipc_msg_build() > > Hi all, > I have accomplished a PoC can help you to confirm this issue. > > And two weeks passed from the last mail, can you tell me the progress of the > patch to this flaw? > > Thanks. > > Qian Zhang > Marvel Team Qihoo 360 > > > -----邮件原件----- > 发件人: Ben Hutchings [mailto:b...@decadent.org.uk] > 发送时间: 2016年10月21日 23:00 > 收件人: Jon Maloy; Ying Xue > 抄送: netdev@vger.kernel.org; 张谦; Eric Dumazet > 主题: Re: [PATCH net] tipc: Guard against tiny MTU in tipc_msg_build() > > On Fri, 2016-10-21 at 14:57 +0000, Jon Maloy wrote: > > > -----Original Message----- > > > > > From: Ben Hutchings [mailto:b...@decadent.org.uk] > > > Sent: Thursday, 20 October, 2016 12:40 > > > > > To: Jon Maloy <jon.ma...@ericsson.com>; Ying Xue > > > > > <ying.x...@gmail.com> > > > > > > > Cc: netdev@vger.kernel.org; Qian Zhang <zhangqia...@360.cn>; > > > > > > > Eric Dumazet > > > > > <eduma...@google.com> > > > Subject: Re: [PATCH net] tipc: Guard against tiny MTU in > > > tipc_msg_build() > > > > > > On Thu, 2016-10-20 at 14:51 +0000, Jon Maloy wrote: > > > [...] > > > > > At this point we're about to copy INT_H_SIZE + mhsz bytes into > > > > > the first fragment. If that's already limited to be less than > > > > > or equal to MAX_H_SIZE, comparing with MAX_H_SIZE would be fine. > > > > > But if > > > > > > MAX_H_SIZE > > > > > is the maximum value of mhsz, that won't be good enough. > > > > > > > > > > > > > > > > MAX_H_SIZE is 60 bytes, but in practice you will never see an mhsz > > > > larger than > > > > > > the biggest header we are actually using, which is MCAST_H_SIZE (==44 > bytes). > > > > INT_H_SIZE is 40 bytes, so you are in reality testing for whether > > > > we have an mtu > > > > > > < 84 bytes. > > > > You won't find any interfaces or protocols that come even close to > > > > this > > > > > > limitation, so to me this test is redundant. > > > > > > But I can easily create such an interface: > > > > > > $ unshare -n -U -r > > > # ip l set lo mtu 1 > > > > > > Ben. > > > > > > It won't be very useful though. But I assume you mean it could be a > > possible exploit, > > Exactly. > > > and I suspect a few other things would break both in TIPC and in > > other stacks if you do anything like that. I think the solution to > > this is not to fix all possible places in the code where this can go > > wrong, but rather to have a generic test where we refuse to attach > > bearers/interfaces offering an mtu < e.g. 1000 bytes. This can easily > > be done in tipc_enable_l2_media(). > > Yes. > > Ben. > > -- > Ben Hutchings > One of the nice things about standards is that there are so many of them.
