aboutsummaryrefslogtreecommitdiffstats
path: root/net/unix/af_unix.c
diff options
context:
space:
mode:
authorVladimir Oltean <[email protected]>2024-05-27 15:39:55 +0000
committerJakub Kicinski <[email protected]>2024-05-29 02:46:41 +0000
commitfb66df20a7201e60f2b13d7f95d031b31a8831d3 (patch)
treeadaf982615c1efa41f6adbd2d0c633faf6283c00 /net/unix/af_unix.c
parentnet/sched: taprio: make q->picos_per_byte available to fill_sched_entry() (diff)
downloadkernel-fb66df20a7201e60f2b13d7f95d031b31a8831d3.tar.gz
kernel-fb66df20a7201e60f2b13d7f95d031b31a8831d3.zip
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. Fixes: b5b73b26b3ca ("taprio: Fix allowing too small intervals") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions