During our testing with chromium implementation, we found more edge cases in complex ops like pool2d and conv2d, where when specifying some unreasonably large sizes of these parameters trigger integer overflows in some of the backends.
In reality, these parameters never have too large values.
If we limit them to smaller and realistic upper bounds that are reasonable for all use cases, it can reduce our attack surface and also make our fuzz testing much more efficient.
WDYT?
We should also go over other complex ops to see where we can harden the limits.
During our testing with chromium implementation, we found more edge cases in complex ops like pool2d and conv2d, where when specifying some unreasonably large sizes of these parameters trigger integer overflows in some of the backends.
In reality, these parameters never have too large values.
If we limit them to smaller and realistic upper bounds that are reasonable for all use cases, it can reduce our attack surface and also make our fuzz testing much more efficient.
WDYT?
We should also go over other complex ops to see where we can harden the limits.