Why isn't this a vulnerability in openzeppelin's ERC-20 implementation (no allowance check)

Question

openzeppelin's implementation of and ERC-20 token is as follows:

function transferFrom(address from, address to, uint256 value) public returns (bool) {
    _transfer(from, to, value);
    _approve(from, msg.sender, _allowed[from][msg.sender].sub(value));
    return true;
}

There is no allowance check in this function, maybe it's in _transfer?

function _transfer(address from, address to, uint256 value) internal {
    require(to != address(0));

    _balances[from] = _balances[from].sub(value);
    _balances[to] = _balances[to].add(value);
    emit Transfer(from, to, value);
}

No allowance check here either? hmmm maybe it's in _approve? But that would be a bit strange...

function _approve(address owner, address spender, uint256 value) internal {
    require(spender != address(0));
    require(owner != address(0));

    _allowed[owner][spender] = value;
    emit Approval(owner, spender, value);
}

still no allowance check. I have to be losing my mind here because there's no way open zeppelin would allow such a glaring and severe vulnerability through right?

Answer 1

The check is implicit here:

_allowed[from][msg.sender].sub(value)

Assuming they're using a library like SafeMath to do that sub, then this will throw if the appropriate allowance isn't available.

Answer 2

I found the answer as I was writing this up, but figured I'd share in case anyone else was confused.

The check is implicit in the _approve params

function transferFrom(address from, address to, uint256 value) public returns (bool) {
_transfer(from, to, value);
_approve(from, msg.sender, _allowed[from][msg.sender].sub(value));
return true;

when calling _allowed[from][msg.sender].sub(value) the .sub function checks if (value) is greater than what it's being subtracted from and reverts if that's the case. So if anyone tries to call the function with a value greater than their allowance the tx will revert.