Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751799AbbLIPv2 (ORCPT ); Wed, 9 Dec 2015 10:51:28 -0500 Received: from smtp-out6.electric.net ([192.162.217.195]:60851 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbbLIPv0 (ORCPT ); Wed, 9 Dec 2015 10:51:26 -0500 From: David Laight To: "'Eric Dumazet'" , Eric Dumazet CC: Marcelo Ricardo Leitner , Dmitry Vyukov , "David S. Miller" , "Alexey Kuznetsov" , James Morris , "Hideaki YOSHIFUJI" , Patrick McHardy , netdev , LKML , "Vlad Yasevich" , Neil Horman , "linux-sctp@vger.kernel.org" , syzkaller , Kostya Serebryany , "Alexander Potapenko" , Sasha Levin Subject: RE: [PATCH net] ipv6: sctp: clone options to avoid use after free Thread-Topic: [PATCH net] ipv6: sctp: clone options to avoid use after free Thread-Index: AQHRMpWwjulvUpSDiUGGxL2XGNkOVJ7Cy09w Date: Wed, 9 Dec 2015 15:49:27 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBE9A61@AcuExch.aculab.com> References: <20151209145917.GA3884@mrl.redhat.com> <1449674706.9768.5.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1449674706.9768.5.camel@edumazet-glaptop2.roam.corp.google.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tB9FpXha026804 Content-Length: 665 Lines: 16 > SCTP is lacking proper np->opt cloning at accept() time. > > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP. > > We might later factorize this code in a common helper to avoid > future mistakes. I'm wondering what the real impact of this and the other recent SCTP bugs/patches is on real workloads? We have enough trouble getting our customers to use kernels later that the 2.6.18 based RHEL5 - without having to persuade them to use kernels that contain very recent fixes. David ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?