Vulnerability: Sushi: redeemToken redeems less than it should
Severity: medium

Description:
The `redeemToken` function takes as argument the amount of SUSHI to redeem. Because the SushiBar's `leave` function - which has to be called to achieve this goal - takes an amount of xSUSHI that is to be burned in exchange for SUSHI, `redeemToken` has to compute the amount of xSUSHI that will result in a return of as many SUSHI tokens as were requested.\\n```\\n/// @notice Redeems tokens from the yield source from the msg.sender, it burn yield bearing tokens and return token to the sender.\\n/// @param amount The amount of `token()` to withdraw. Denominated in `token()` as above.\\n/// @return The actual amount of tokens that were redeemed.\\nfunction redeemToken(uint256 amount) public override returns (uint256) {\\n    ISushiBar bar = ISushiBar(sushiBar);\\n    ISushi sushi = ISushi(sushiAddr);\\n\\n    uint256 totalShares = bar.totalSupply();\\n    uint256 barSushiBalance = sushi.balanceOf(address(bar));\\n    uint256 requiredShares = amount.mul(totalShares).div(barSushiBalance);\\n\\n    uint256 barBeforeBalance = bar.balanceOf(address(this));\\n    uint256 sushiBeforeBalance = sushi.balanceOf(address(this));\\n\\n    bar.leave(requiredShares);\\n\\n    uint256 barAfterBalance = bar.balanceOf(address(this));\\n    uint256 sushiAfterBalance = sushi.balanceOf(address(this));\\n\\n    uint256 barBalanceDiff = barBeforeBalance.sub(barAfterBalance);\\n    uint256 sushiBalanceDiff = sushiAfterBalance.sub(sushiBeforeBalance);\\n\\n    balances[msg.sender] = balances[msg.sender].sub(barBalanceDiff);\\n    sushi.transfer(msg.sender, sushiBalanceDiff);\\n    return (sushiBalanceDiff);\\n}\\n```\\n\\nBecause the necessary calculations involve division and amounts have to be integral values, it is usually not possible to get the exact amount of SUSHI tokens that were requested. More precisely, let `a` denote the total supply of xSUSHI and `b` the SushiBar's balance of SUSHI at `a` certain point in time. If the SushiBar's `leave` function is supplied with `x` xSUSHI, then it will transfer floor(x * `b` / a) SUSHI. (We assume throughout this discussion that the numbers involved are small enough such that no overflow occurs and that `a` and `b` are not zero.)\\nHence, if `y` is the amount of SUSHI requested, it would make sense to call `leave` with the biggest number `x` that satisfies floor(x * b / a) <= `y` or the smallest number `x` that satisfies `floor(x * b / a) >= y`. Which of the two is “better” or “correct” needs to be specified, based on the requirements of the caller of `redeemToken`. It seems plausible, though, that the first variant is the one that makes more sense in this context, and the current implementation of `redeemToken` supports this hypothesis. It calls `leave` with `x1 := floor(y * a / b)`, which gives us floor(x1 * b / a) <= `y`. However, `x1` is not necessarily the biggest number that satisfies the relation, so the caller of `redeemToken` might end up with less SUSHI than they could have gotten while still not exceeding `y`.\\nThe correct amount to call `leave` with isx2 := floor((y * a + a - 1) / b) = max { x | floor(x * b / a) <= y }. Since `|x2 - x1| <= 1`, the difference in SUSHI is at most `floor(b / a)`. Nevertheless, even this small difference might subvert fairly reasonable expectations. For example, if someone queries `balanceOfToken` and immediately after that feeds the result into `redeemToken`, they might very well expect to redeem exactly the given amount and not less; it's their current balance, after all. However, that's not always the case with the current implementation.

Impact:

Recommended mitigation:
Calculate `requiredShares` based on the formula above (x2). We also recommend dealing in a clean way with the special cases `totalShares == 0` and `barSushiBalance == 0`.