Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 577482 (CVE-2016-2315)

Summary: <dev-vcs/git-2.7.3-r1: buffer overflow (CVE-2016-2315)
Product: Gentoo Security Reporter: Agostino Sarubbo <ago>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: dan, polynomial-c, robbat2, ytrezq
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also:
Whiteboard: B2 [glsa cve]
Package list:
Runtime testing required: ---

Description Agostino Sarubbo gentoo-dev 2016-03-15 15:13:46 UTC
From ${URL} :

> The problem you describe is one where the size of the allocation does
> not match what strcpy would write. And that's kind-of fixed by moving to
> memcpy() in 34fa79a6, because at least now the initial value of "len"
> matches the number of bytes we write (so that number might be totally
> bogus, but we don't write more than we allocate).
> But "len" can also change after the fact, due to the loop. If you have a
> sequence of path components, each less than 2^31, they can sum to a much
> smaller positive value due to integer overflow (e.g., A/B/C with lengths
> A=2^31-5, B=2^31-5, C=20 would yield len=10). Then the buffer is too
> small to fit C, let alone all of the extra components we insert in the
> second loop.
> The fix I came up with for this is to convert all of the "int" variables
> here to "size_t". That doesn't actually _fix_ the problem at all, but
> does mean on a 64-bit system that you need a 2^64-long path to trigger
> it, which is impractical. But that doesn't help 32-bit systems (though
> in practice, I wouldn't be surprised if we barf long before that, as we
> would be unable to hold the "struct name_path" list in memory).
> Note that there is also a similar problem in tree-diff.c's
> path_appendnew().  There we build up the full pathname in a strbuf,
> which checks for overflow. But we then pass that length as an int and
> allocate a FLEX_ARRAY struct with it, which can end up too-small. This
> one is the more interesting of the two, I think, as it triggers via
> git-log, whereas the path_name() happens only during a repack (so it
> will hit you _eventually_, but probably not as soon as you've cloned).
> My solution there was similar: use size_t, which at least means you'd
> have to allocate petabytes on a 64-bit system to trigger it (much less
> on a 32-bit system, but _probably_ you'd be saved by malloc failing
> first).
> And that's why I dragged my feet on sending those fixes upstream; I
> don't think they're complete. The complete fix would be to use size_t
> consistently to store return values for strlen(), and to do integer
> overflow checks whenever we do computations on size_t.
> Those of you on this list may recall I posted a series for the latter
> last year, but it was somewhat invasive. It may be worth resurrecting.
> I think we could also get rid of path_name() entirely. The sole purpose
> at this point is to compute the name-hash for pack-objects, which could
> be done by walking the name_path list rather than re-constructing the
> whole thing in memory.

Fixed in 2.7.1

@maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-03-15 15:24:29 UTC
I'd go with =dev-vcs/git-2.7.3 but that's up for Robin to decide...
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-15 19:07:55 UTC
+1 to stable 2.7.3
Comment 3 Aaron Bauman (RETIRED) gentoo-dev 2016-03-15 23:12:58 UTC
@arches, please stabilize dev-vcs/git-2.7.3

TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc64, ppc, sparc, x86, arm64, s390, sh
Comment 4 Agostino Sarubbo gentoo-dev 2016-03-16 10:59:08 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2016-03-16 11:01:01 UTC
x86 stable
Comment 6 Agostino Sarubbo gentoo-dev 2016-03-16 12:08:59 UTC
ppc stable
Comment 7 Hanno Böck gentoo-dev 2016-03-16 13:20:12 UTC
There just was a message to oss-security that 2.7.3 actually does not contain the fix:

The post links to patches, not sure when git will make a new release, maybe they should be backported to our ebuild.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-16 19:07:34 UTC
I'm running the testsuite on the backported patch now; if it passes I'll push an -r1 and we can restart stable.
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-16 20:32:51 UTC
@hanno: backported now.

@arches, please stabilize dev-vcs/git-2.7.3-r1

TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc64, ppc, sparc, x86, arm64, s390, sh

Apologies for the second round of stablization; upstream didn't actually have the fix in 2.7.3.
Comment 10 Agostino Sarubbo gentoo-dev 2016-03-17 10:02:30 UTC
 Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/x86
Comment 11 ytrezq 2016-03-17 11:56:44 UTC
Remember due the nature of the bug, it might be impossible to trigger ʀᴄᴇ on big endian machines.
Comment 12 ytrezq 2016-03-17 12:56:38 UTC
So such architectures might be safe.
Comment 13 Oleh 2016-03-18 10:23:36 UTC
New versions of git available: 2.4.11, 2.5.5,  2.6.6, 2.7.4 which should have this security bug fixed, i.e no backports needed.
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2016-03-20 10:22:01 UTC
Stable for HPPA.
Comment 15 Aaron Bauman (RETIRED) gentoo-dev 2016-03-25 13:04:40 UTC
@maintainers, please cleanup vulnerable versions.  Thank you.
Comment 16 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-26 01:27:21 UTC
cleanup done
Comment 17 GLSAMaker/CVETool Bot gentoo-dev 2016-05-02 19:40:09 UTC
This issue was resolved and addressed in
 GLSA 201605-01 at
by GLSA coordinator Kristian Fiskerstrand (K_F).
Comment 18 Thomas Deutschmann (RETIRED) gentoo-dev 2017-02-14 19:07:53 UTC
Fixing alias encoding.