2.84 is same as 2.83 but with security bug fixed: http://trac.transmissionbt.com/wiki/Changes#version-2.84 Transmission 2.84 (2014/07/01) Fix peer communication vulnerability (no known exploits) reported by Ben Hawkes
Please test and stabilize: =net-p2p/transmission-2.84
Tried to find the vulnerability. This looks like it: proof-of-concept for tr_bitfieldEnsureNthBitAlloced overflow: tr_bitfieldEnsureBitsAlloced (b, nth + 1); ... b->bits[nth >> 3u] |= (0x80 >> (nth & 7u)); results in a 1-bit out-of-bound write at constant address 0x1fffffff affects 32-bit systems only due to int index being cast to size_t nth its also possible to trigger the write relative to an allocated chunk by sending a valid response to the first piece request and triggering the bug on the second piece request (such that b->bits is allocated) submission acts as a seeding peer for the provided torrent file by default, transmission clients will use uTP and encryption, which submission doesn't support. tested using the following client: transmission-2.83/daemon/transmission-daemon -et --no-utp -f -c . thanks! - hawkes (hawkes@inertiawar.com)
Arches, please test and mark stable: =net-p2p/transmission-2.84 Target Keywords : "amd64 ppc ppc64 x86" Thank you!
amd64 stable
x86 stable
ppc stable
ppc64 stable. Maintainer(s), please cleanup. Security, please vote.
cleanup done
Arches and Maintainer(s), Thank you for your work. GLSA Vote: No
GLSA vote: No
CVE-2014-4909 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-4909): Integer overflow in the tr_bitfieldEnsureNthBitAlloced function in bitfield.c in Transmission before 2.84 allows remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted peer message, which triggers an out-of-bounds write.