In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot.
4.13.0-16.195.3.0-18.195.3.0-24.265.4.0-100.1135.4.0-104.1185.4.0-105.1195.4.0-107.1215.4.0-109.1235.4.0-110.1245.4.0-113.1275.4.0-117.132+109 more6.11.0-8.84.2.0-16.194.2.0-17.214.2.0-19.234.3.0-1.104.3.0-2.114.3.0-5.164.3.0-6.174.3.0-7.184.4.0-2.163.11.0-12.195.13.0-19.195.15.0-100.1105.15.0-101.1115.15.0-102.1125.15.0-105.1155.15.0-106.1165.15.0-107.1175.15.0-112.1225.15.0-113.1235.15.0-116.126+67 more6.5.0-9.96.6.0-14.146.8.0-11.116.8.0-20.206.8.0-22.226.8.0-28.286.8.0-31.316.8.0-35.356.8.0-36.366.8.0-38.38+3 more6.8.0-44.445.19.0-1007.7~22.04.15.19.0-1009.9~22.04.15.19.0-1010.10~22.04.15.19.0-1011.11~22.04.15.19.0-1012.12~22.04.15.19.0-1013.13~22.04.15.19.0-1014.14~22.04.15.19.0-1015.15~22.04.15.13.0-1005.65.15.0-1002.45.15.0-1003.55.15.0-1004.65.15.0-1005.75.15.0-1008.105.15.0-1009.115.15.0-1011.145.15.0-1013.175.15.0-1014.18+59 more6.5.0-1008.86.6.0-1001.16.8.0-1001.16.8.0-1006.66.8.0-1008.86.8.0-1009.96.8.0-1010.106.8.0-1011.126.8.0-1012.136.8.0-1013.14+1 more6.8.0-1015.16