There is a reproducible sequence from the userland that will trigger a WARN_ON() condition in taprio_get_start_time, which causes kernel to panic if configured as "panic_on_warn". Catch this during initialisation in parse_taprio_schedule to prevent this condition.
Reported as bug on syzkaller: https://syzkaller.appspot.com/bug?extid=d50710fd0873a9c6b40c Reported-by: syzbot+d50710fd0873a9c6b...@syzkaller.appspotmail.com Signed-off-by: Du Cheng <duche...@gmail.com> --- changelog v1: Discussion https://lore.kernel.org/netdev/YHfwUmFODUHx8G5W@carbon/T/ v2: fix typo https://lore.kernel.org/netdev/20210415075953.83508-2-duche...@gmail.com/T/ v3: catch the condition in parse_taprio_schedule instead net/sched/sch_taprio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c index 8287894541e3..abd6b176383c 100644 --- a/net/sched/sch_taprio.c +++ b/net/sched/sch_taprio.c @@ -901,6 +901,10 @@ static int parse_taprio_schedule(struct taprio_sched *q, struct nlattr **tb, list_for_each_entry(entry, &new->entries, list) cycle = ktime_add_ns(cycle, entry->interval); + + if (!cycle) + return -EINVAL; + new->cycle_time = cycle; } -- 2.30.2
