Submitted by t0x1c, also found by Draiakoo and AgileJune
_zapSwapAmount() assumes that:
The protocols assumption of r1 * z0 guaranteed to be greater than r0 * z1 is based on the following check in _determineZapSwapAmount():
The assumption would had been true for all cases if not for this piece of logic inside _zapSwapAmount()#L158-L168 which right shifts the arguments if the maximumMSB is greater than 80:
This can lead to z0 being reduced to 0 and hence causing underflow on L192. 
Since _determineZapSwapAmount() is internally called whenever depositLiquidityAndIncreaseShare() is called with useZapping = true, it will cause a revert when a situation like the following exists:
maximumMSB in this case is 90 (for reserveB) and also an excess of zapAmountA is being provided as compared to the existing reserve ratio. Hence, right shift by 90 - 80 = 10 bits will occur resulting z0 to be 0.
Create a new file src/stable/tests/BugPoolMath.t.sol and add the following code. Run it via forge test -vv --mt test_poolMath to see the test revert:
Foundry
Make sure to check the assertion again:
othernet-global (Salty.IO) confirmed and commented:
Status: Mitigation confirmed. Full details in reports from zzebra83, 0xpiken, and t0x1c.
