I can confirm the bug. It seems we don't handle correctly the case of content alignment in a grid with indefinite size.

After investigating the issue for a while, I came to the conclusion that the current behavior is not a bug, but a consequence of how we interpret the default value of the overflow-alignment.

We currently use 'unsafe' as behavior for the default overflow-alignment value. We do this because the spec stated that, at some point. It seems that now the text is quite different, which states the following:

https://drafts.csswg.org/css-align/#overflow-values
"If the overflow alignment isn’t explicitly specified, the default overflow alignment is similar to unsafe in that an overflowing alignment subject is allowed to overflow its alignment container; however if the this would cause it to also overflow the scrollable overflow region of its nearest ancestor scroll container, then its overflow in that direction is limited by biasing any remaining overflow to the end side. In other words, it is similar to safe alignment except that the limit for switching to start is triggered by overflowing the scrollable area, rather than merely overflowing the alignment container."

I don't fully understand the implications of the new behavior, so I'd rather keep it as it is, for now, assuming "unsafe" as default. 

If we replace "end" by "end safe" in the attached test case we get the same results than Firefox. 

Another possibility is that the issue is not related to alignment at all, but how we compute the grid's intrinsic height.  

Huh? the attached testcase has no overflow whatsoever so overflow-alignment
is irrelevant.

https://drafts.csswg.org/css-align-3/#distribution-grid
For a Grid container, the Alignment Subjects are the rows and the Alignment Container is the grid container’s content box.  Thus, align-content:end
should pile up the rows at the end of the content box.  There is only one
row in the testcase, so that row's end edge should coincide with the end
content edge of its container.  Given that the row size and the content
area are both 50px you don't have to adjust the row's position at all.
As I said, the two grids should render exactly the same.

(FYI, overflow-alignment only comes into play when the tracks overflow
the content area, e.g. "grid: 50px / 50px; height: 25px")

Yeah, the problem is that we are getting a wrong value (-50px) as the available space for alignment. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/02c5917e79b05910149b2e6eff680673d6e4a9b0

commit 02c5917e79b05910149b2e6eff680673d6e4a9b0
Author: jfernandez <jfernandez@igalia.com>
Date: Thu Oct 20 13:27:54 2016

[css-grid] Computing free space on indefinite sized grids

The Grid Tracks sizing algorithm updates receives the available space
to be used as space for tracks. We hold a variable to store the
remaining free space for each dimension.

When the grid container size is indefinite we can't compute the
available free space after computing track sizes until such indefinite
size is resolved.

BUG= 655390 

Review-Url: https://chromiumcodereview.appspot.com/2415313003
Cr-Commit-Position: refs/heads/master@{#426464}

[delete] https://crrev.com/e687fefd7265a5e4cc580e73d6e0e028ed52c24c/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-content-alignment-overflow-expected.txt
[modify] https://crrev.com/02c5917e79b05910149b2e6eff680673d6e4a9b0/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-content-alignment-overflow.html
[modify] https://crrev.com/02c5917e79b05910149b2e6eff680673d6e4a9b0/third_party/WebKit/Source/core/layout/LayoutGrid.cpp

This issue should be FIXED now.