The first problem is that it's not threadsafe, and the string buffer that is used doesn't contain a trustworthy value; i.e., you can't be sure the value you get back is any good. US-CERT goes into some detail.
The results of getlogin() should not be trusted.
The getlogin() function returns a pointer to a string that contains
the name of the user associated with the calling process. The function
is not reentrant, meaning that if it is called from another process,
the contents are not locked out and the value of the string can be
changed by another process. This makes it very risky to use because
the username can be changed by other processes, so the results of the
function cannot be trusted.
US-CERT has more details on the issue. One alternative is to use the threadsafe version getlogin_r(), or to use other mechanisms.
The second problem is that there is a known flaw in SSH that allows attackers to specifically spoof the result of getlogin():
On platforms relying on getlogin() (mainly the different BSD variants)
malicious users can at least send misleading messages to syslog and
others applications (getlogin() call will return "root").
Rapid7 has additional details as well.