No description
ebffa40aa7
The definition of the splay_each() macro is somewhat complicated for
syntactic reasons. Here's what it does in a more readable way:
for (splay_node_t* node = tree->head; node;) {
type* item = node->data;
splay_node_t* next = node->next;
// RUN USER BLOCK with (item)
node = next;
}
list_each() works in the same way. Since node->next is saved before the
user block runs, this construct supports removing the current item from
within the user block. However, what it does *not* support is removing
*other items* from within the user block, especially the next item.
Indeed, that will invalide the next pointer in the above loop and
therefore result in an invalid pointer dereference.
Unfortunately, there is at least one code path where that unsupported
operation happens. It is located in ack_h(), where the authentication
protocol code detects a double connection (i.e. being connected to
another node twice). Running in the context of a socket read event, this
code will happily terminate the *other* metaconnection, resulting in its
socket being removed from the io tree. If, by misfortune, this other
metaconnection happened to have the next socket FD number (which is
quite possible due to FD reuse - albeit unlikely), and was part of the
io tree (which is quite likely because if that connection is stuck, it
will most likely have pending writes) then this will result in the next
pending io item being destroyed. Invalid pointer dereference ensues.
I did a quick audit of other uses of splay_each() and list_each() and
I believe this is the only scenario in which this "next pointer
invalidation" problem can occur in practice. While this bug has been
there since at least
|
||
|---|---|---|
| bash_completion.d | ||
| doc | ||
| gui | ||
| m4 | ||
| src | ||
| test | ||
| .gitignore | ||
| AUTHORS | ||
| configure.ac | ||
| COPYING | ||
| COPYING.README | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.android | ||
| README.git | ||
| THANKS | ||
This is the README file for tinc version 1.1pre11. Installation instructions may be found in the INSTALL file. tinc is Copyright (C) 1998-2014 by: Ivo Timmermans, Guus Sliepen <guus@tinc-vpn.org>, and others. For a complete list of authors see the AUTHORS file. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See the file COPYING for more details. This is a pre-release --------------------- Please note that this is NOT a stable release. Until version 1.1.0 is released, please use one of the 1.0.x versions if you need a stable version of tinc. Although tinc 1.1 will be protocol compatible with tinc 1.0.x, the functionality of the tinc program may still change, and the control socket protocol is not fixed yet. Security statement ------------------ This version uses an experimental and unfinished cryptographic protocol. Use it at your own risk. Compatibility ------------- Version 1.1pre11 is compatible with 1.0pre8, 1.0 and later, but not with older versions of tinc. When the ExperimentalProtocol option is used, tinc is still compatible with 1.0.X and 1.1pre11 itself, but not with any other 1.1preX version. Requirements ------------ In order to compile tinc, you will need a GNU C compiler environment. Please ensure you have the latest stable versions of all the required libraries: - OpenSSL (http://www.openssl.org/) version 1.0.0 or later, with support for elliptic curve cryptography (ECC) and Galois counter mode (GCM) enabled. The following libraries are used by default, but can be disabled if necessary: - zlib (http://www.gzip.org/zlib/) - lzo (http://www.oberhumer.com/opensource/lzo/) - ncurses (http://invisible-island.net/ncurses/) - readline (ftp://ftp.gnu.org/pub/gnu/readline/) Features -------- Tinc is a peer-to-peer VPN daemon that supports VPNs with an arbitrary number of nodes. Instead of configuring tunnels, you give tinc the location and public key of a few nodes in the VPN. After making the initial connections to those nodes, tinc will learn about all other nodes on the VPN, and will make connections automatically. When direct connections are not possible, data will be forwarded by intermediate nodes. By default, nodes authenticate each other using 2048 bit RSA (or 521 bit ECDSA*) keys. Traffic is encrypted using Blowfish in CBC mode (or AES-256 in GCM mode*), authenticated using HMAC-SHA1 (or GCM*), and is protected against replay attacks. *) When using the ExperimentalProtocol option. Tinc fully supports IPv6. Tinc can operate in several routing modes. In the default mode, "router", every node is associated with one or more IPv4 and/or IPv6 Subnets. The other two modes, "switch" and "hub", let the tinc daemons work together to form a virtual Ethernet network switch or hub. Normally, when started tinc will detach and run in the background. In a native Windows environment this means tinc will intall itself as a service, which will restart after reboots. To prevent tinc from detaching or running as a service, use the -D option. The status of the VPN can be queried using the "tinc" command, which connects to a running tinc daemon via a control connection. The same tool also makes it easy to start and stop tinc, and to change its configuration.