From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> To: David Laight <David.Laight@ACULAB.COM>, "'Eric Dumazet'" <eric.dumazet@gmail.com> Cc: Eric Dumazet <edumazet@google.com>, Dmitry Vyukov <dvyukov@google.com>, "David S. Miller" <davem@davemloft.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, James Morris <jmorris@namei.org>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>, Patrick McHardy <kaber@trash.net>, netdev <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Vlad Yasevich <vyasevich@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, syzkaller <syzkaller@googlegroups.com>, Kostya Serebryany <kcc@google.com>, Alexander Potapenko <glider@google.com>, Sasha Levin <sasha.levin@oracle.com> Subject: Re: [PATCH net] ipv6: sctp: clone options to avoid use after free Date: Wed, 9 Dec 2015 15:11:24 -0200 [thread overview] Message-ID: <566860BC.4040604@gmail.com> (raw) In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CBE9B1C@AcuExch.aculab.com> Em 09-12-2015 14:31, David Laight escreveu: > From: Eric Dumazet [mailto:eric.dumazet@gmail.com] >> Sent: 09 December 2015 16:00 >> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote: >>>> 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. >> >> It all depends if your customers let (hostile ?) people run programs on >> the boxes. > > If they require hostile programs I'm not worried. Not really "require", but "allow", as in: allowing third-party applications to run on it. > But it isn't entirely clear from these oops reports what the > test program is actually doing. > Some of them might be valid scenarios. > Not that our code does anything clever. This one patched by Eric is a rather common scenario and can lead to memory corruption and even double-frees because it will call txopt_put() on a buffer that is long gone due to the blind pointer copy. Note that Vlad is checking peeloff operation yet regarding this. You just have to use the right SOL_IPV6 options and accept a socket to trigger it. The timestamps I patched are also not an unusual scenario and allow one to be able to disable packet stamping for the entire system. Another effect would be to one enable stamping on listening socket and not gett it automatically on accepted ones, but that's probably a minor compared to the others because developers probably would have caught this already. And this last one I'm still fixing, is mostly harmless so far. The use-after-free happens only in a debug statement (read: not propagated anywhere else) and it's just a read. HTH! Marcelo
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> To: David Laight <David.Laight@ACULAB.COM>, 'Eric Dumazet' <eric.dumazet@gmail.com> Cc: Eric Dumazet <edumazet@google.com>, Dmitry Vyukov <dvyukov@google.com>, "David S. Miller" <davem@davemloft.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, James Morris <jmorris@namei.org>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>, Patrick McHardy <kaber@trash.net>, netdev <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Vlad Yasevich <vyasevich@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>, syzkaller <syzkaller@googlegroups.com>, Kostya Serebryany <kcc@google.com>, Alexander Potapenko <glider@google.com>, Sasha Levin <sasha.levin@oracle.com> Subject: Re: [PATCH net] ipv6: sctp: clone options to avoid use after free Date: Wed, 09 Dec 2015 17:11:24 +0000 [thread overview] Message-ID: <566860BC.4040604@gmail.com> (raw) In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CBE9B1C@AcuExch.aculab.com> Em 09-12-2015 14:31, David Laight escreveu: > From: Eric Dumazet [mailto:eric.dumazet@gmail.com] >> Sent: 09 December 2015 16:00 >> On Wed, 2015-12-09 at 15:49 +0000, David Laight wrote: >>>> 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. >> >> It all depends if your customers let (hostile ?) people run programs on >> the boxes. > > If they require hostile programs I'm not worried. Not really "require", but "allow", as in: allowing third-party applications to run on it. > But it isn't entirely clear from these oops reports what the > test program is actually doing. > Some of them might be valid scenarios. > Not that our code does anything clever. This one patched by Eric is a rather common scenario and can lead to memory corruption and even double-frees because it will call txopt_put() on a buffer that is long gone due to the blind pointer copy. Note that Vlad is checking peeloff operation yet regarding this. You just have to use the right SOL_IPV6 options and accept a socket to trigger it. The timestamps I patched are also not an unusual scenario and allow one to be able to disable packet stamping for the entire system. Another effect would be to one enable stamping on listening socket and not gett it automatically on accepted ones, but that's probably a minor compared to the others because developers probably would have caught this already. And this last one I'm still fixing, is mostly harmless so far. The use-after-free happens only in a debug statement (read: not propagated anywhere else) and it's just a read. HTH! Marcelo
next prev parent reply other threads:[~2015-12-09 17:11 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-09 14:15 use-after-free in inet6_destroy_sock Dmitry Vyukov 2015-12-09 14:15 ` Dmitry Vyukov 2015-12-09 14:43 ` Eric Dumazet 2015-12-09 14:43 ` Eric Dumazet 2015-12-09 14:59 ` Marcelo Ricardo Leitner 2015-12-09 14:59 ` Marcelo Ricardo Leitner 2015-12-09 15:09 ` Eric Dumazet 2015-12-09 15:09 ` Eric Dumazet 2015-12-09 15:25 ` [PATCH net] ipv6: sctp: clone options to avoid use after free Eric Dumazet 2015-12-09 15:25 ` Eric Dumazet 2015-12-09 15:34 ` Vlad Yasevich 2015-12-09 15:34 ` Vlad Yasevich 2015-12-09 15:49 ` David Laight 2015-12-09 15:49 ` David Laight 2015-12-09 15:49 ` David Laight 2015-12-09 15:59 ` Eric Dumazet 2015-12-09 15:59 ` Eric Dumazet 2015-12-09 16:31 ` David Laight 2015-12-09 16:31 ` David Laight 2015-12-09 16:31 ` David Laight 2015-12-09 17:11 ` Marcelo Ricardo Leitner [this message] 2015-12-09 17:11 ` Marcelo Ricardo Leitner 2015-12-09 19:19 ` Daniel Borkmann 2015-12-09 19:19 ` Daniel Borkmann 2015-12-10 12:26 ` David Laight 2015-12-10 12:26 ` David Laight 2015-12-10 12:26 ` David Laight 2015-12-10 15:58 ` Eric Dumazet 2015-12-10 15:58 ` Eric Dumazet 2015-12-10 17:27 ` David Laight 2015-12-10 17:27 ` David Laight 2015-12-10 17:27 ` David Laight 2015-12-12 1:19 ` David Miller 2015-12-12 1:19 ` David Miller
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=566860BC.4040604@gmail.com \ --to=marcelo.leitner@gmail.com \ --cc=David.Laight@ACULAB.COM \ --cc=davem@davemloft.net \ --cc=dvyukov@google.com \ --cc=edumazet@google.com \ --cc=eric.dumazet@gmail.com \ --cc=glider@google.com \ --cc=jmorris@namei.org \ --cc=kaber@trash.net \ --cc=kcc@google.com \ --cc=kuznet@ms2.inr.ac.ru \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sctp@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=sasha.levin@oracle.com \ --cc=syzkaller@googlegroups.com \ --cc=vyasevich@gmail.com \ --cc=yoshfuji@linux-ipv6.org \ /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: linkBe 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.