[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBEC96A@AcuExch.aculab.com>
Date: Mon, 14 Dec 2015 09:50:36 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Vlad Yasevich' <vyasevich@...il.com>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>
CC: netdev <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
syzkaller <syzkaller@...glegroups.com>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
Kostya Serebryany <kcc@...gle.com>,
"Alexander Potapenko" <glider@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: RE: use-after-free in sctp_do_sm
From: Vlad Yasevich
> Sent: 11 December 2015 18:38
...
> > Found a similar place in abort primitive handling like in this last
> > patch update, it's probably the issue you're still triggering.
> >
> > Also found another place that may lead to this use after free, in case
> > we receive a packet with a chunk that has no data.
> >
> > Oh my.. :)
>
> Yes. This is what I was worried about... Anything that triggers
> a DELTE_TCB command has to return a code that we can trap.
>
> The other way is to do what Dmitri suggested, but even there, we
> need to be very careful.
I'm always wary of anything that queues actions up for later processing.
It is far too easy (as found here) to end up processing actions
in invalid states, or to process actions in 'unusual' orders when
specific events happen close together.
I wonder how much fallout there'd be from getting the sctp code
to immediately action things, instead of queuing the actions for later.
It would certainly remove a lot of the unusual combinations of events.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists