From https://secunia.com/advisories/51329/ :
A vulnerability has been reported in Tor, which can be exploited by malicious people to cause a DoS
(Denial of Service).
The vulnerability is caused due to an error when handling SENDME cells and can be exploited to e.g.
cause excessive consumption of memory resources within an entry node.
Upgrade to version 0.2.3.25.
@maintainer, can we stabilize 0.2.3.25 ?
(In reply to comment #1)
> @maintainer, can we stabilize 0.2.3.25 ?
I knew this was coming, so I got everything ready. Arch teams target
KEYWORDS="~amd64 ~arm ~ppc ~ppc64 ~sparc ~x86"
I'll take care of arm, ppc and ppc64 in a minute.
stable on arm ppc ppc64
@sparc. I had USE=nat-pmp and USE=upnp masked for net-misc/tor across all arches and just unmasked them for amd64 and x86. Testing on arm, mips, ppc and pp64 showed that they now work there so I unmasked them for *all* arches.
When stabilizing tor for sparc, please also test net-libs/libnatpmp and net-libs/miniupnpc and either keyword/stabilize or mask those flags.
GLSA vote: yes.
GLSA request filed.
The connection_edge_process_relay_cell function in or/relay.c in Tor before
0.2.3.25 maintains circuits even if an unexpected SENDME cell arrives, which
might allow remote attackers to cause a denial of service (memory
consumption or excessive cell reception rate) or bypass intended
flow-control restrictions via a RELAY_COMMAND_SENDME command.
This issue was resolved and addressed in
GLSA 201301-03 at http://security.gentoo.org/glsa/glsa-201301-03.xml
by GLSA coordinator Sean Amoss (ackle).