Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
From: Marcelo Ricardo Leitner
Date: Wed Dec 09 2015 - 12:11:36 EST
Em 09-12-2015 14:31, David Laight escreveu:
From: Eric Dumazet [mailto:eric.dumazet@xxxxxxxxx]
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/