Tor before 0.2.8.9 and 0.2.9.x before 0.2.9.4-alpha had internal functions that were entitled to expect that buf_t data had NUL termination, but the implementation of or/buffers.c did not ensure that NUL termination was present, which allows remote attackers to cause a denial of service (client, hidden service, relay, or authority crash) via crafted data.
Tor before 0.2.4.23 and 0.2.5 before 0.2.5.6-alpha maintains a circuit after an inbound RELAY_EARLY cell is received by a client, which makes it easier for remote attackers to conduct traffic-confirmation attacks by using the pattern of RELAY and RELAY_EARLY cells as a means of communicating information about hidden service names.
Tor before 0.2.3.23-rc allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a renegotiation attempt that occurs after the initiation of the V3 link protocol.
Tor before 0.2.3.24-rc allows remote attackers to cause a denial of service (assertion failure and daemon exit) by performing link protocol negotiation incorrectly.
Tor before 0.2.4.20, when OpenSSL 1.x is used in conjunction with a certain HardwareAccel setting on Intel Sandy Bridge and Ivy Bridge platforms, does not properly generate random numbers for (1) relay identity keys and (2) hidden-service identity keys, which might make it easier for remote attackers to bypass cryptographic protection mechanisms via unspecified vectors.
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.