]> git.hungrycats.org Git - linux/commit
net/sched: taprio: extend minimum interval restriction to entire cycle too
authorVladimir Oltean <vladimir.oltean@nxp.com>
Tue, 19 Nov 2024 08:06:18 +0000 (16:06 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 22 Nov 2024 14:37:34 +0000 (15:37 +0100)
commit34d83c3e6e97867ae061d14eb52123404aab1cbc
treef48faf043066c704c89d1ae86574b24f4be9c170
parentb2c664df3bb46aabac6a5fd78aaa5bd614cfad97
net/sched: taprio: extend minimum interval restriction to entire cycle too

[ Upstream commit fb66df20a7201e60f2b13d7f95d031b31a8831d3 ]

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.

Fixes: b5b73b26b3ca ("taprio: Fix allowing too small intervals")
Reported-by: syzbot+a7d2b1d5d1af83035567@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/0000000000007d66bc06196e7c66@google.com/
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20240527153955.553333-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/sched/sch_taprio.c
tools/testing/selftests/tc-testing/tc-tests/qdiscs/taprio.json