Solidity smart contract audit - ethereum

Question

I have a solidity code to audit like this
pragma solidity ^0.8.0;
import "#openzeppelin/contracts/token/ERC20/IERC20.sol";
// Allow to split the balance through complex rules
interface Split{
function getAddressAndAmountToSplit() view external returns(address, uint);
}
// MyBank contract
// This contract allows anyone to store any ERC20 tokens
contract MyBank {
// (token => user => amount)
mapping (address => mapping(address => uint)) public userBalance;
// (address => Split contract)
mapping (address => Split) splits;
// Deposit ERC20 tokens to the contracts
// The user must approve the bank before calling addToBalance
function addToBalance(IERC20 token, uint amount) external {
token.transferFrom(msg.sender, address(this), amount);
userBalance[address(token)][msg.sender] += amount;
}
// Withdraw part of the balance
function withdrawBalance(IERC20 token) external {
token.transfer(msg.sender, userBalance[address(token)][msg.sender]);
userBalance[address(token)][msg.sender] = 0;
}
// Allow to register a split contract
function registerSplit(Split split) external {
splits[msg.sender] = split;
}
// Split the balance into two accounts
// The usage of a Split contract allows to create complex split strategies
function splitBalance(IERC20 token) external {
Split split = splits[msg.sender];
require(split != Split(address(0x0)));
uint balance = userBalance[address(token)][msg.sender];
(address dest, uint amount) = Split(split).getAddressAndAmountToSplit();
userBalance[address(token)][dest] = amount;
userBalance[address(token)][msg.sender] = balance - amount;
}
}
What I found.
function withdrawBalance(IERC20 token) external possible reentrancy attack, because we check balance in the end
function splitBalance(IERC20 token) external - vulnerable business logic, because if amount is greater than balance we get negative value and possible integer overflow
If you have any idea of possible vulnerabilities of code above, please feel free to provide any further assistance

Answer 1

Probably a bit late but if anyone reads this for why I think these aren’t vulnerabilities. First of all, there are no reentrancy attacks possible here, due to the fact that transfer function only forwards 2300 gas, which is quite not enough to execute something meaningful.
Secondly, its possible to add a require check if balance is bigger than the amount. But since contract is using later than or equal to 0.8.0 compiler versions, if amount is indeed bigger than balance, it will automatically revert due to underflow.
I think as a smart contract auditor, you should know these better.