[syzbot] [net?] WARNING in taprio_get_start_time (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: b549faa950e6 Merge branch 'net-bcmasp-add-support-for-gro'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1003d10c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c07f08ee4bcfb276
dashboard link: https://syzkaller.appspot.com/bug?extid=398e1ee4ca2cac05fddb
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6f82898e05e9/disk-b549faa9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/df2850948ac5/vmlinux-b549faa9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2d4c1db8f02d/bzImage-b549faa9.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+398e1e...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 1 PID: 11372 at net/sched/sch_taprio.c:1223 taprio_get_start_time+0x15e/0x190 net/sched/sch_taprio.c:1223
Modules linked in:
CPU: 1 UID: 0 PID: 11372 Comm: syz.0.1394 Not tainted 6.16.0-rc1-syzkaller-00189-gb549faa950e6 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:taprio_get_start_time+0x15e/0x190 net/sched/sch_taprio.c:1223
Code: 42 80 3c 28 00 74 08 48 89 df e8 5d bd 9d f8 4c 89 23 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d e9 99 ef e2 01 cc e8 e3 44 3a f8 90 <0f> 0b 90 b8 f2 ff ff ff eb e0 44 89 e9 80 e1 07 80 c1 03 38 c1 0f
RSP: 0018:ffffc9000478eee8 EFLAGS: 00010287
RAX: ffffffff89861a0d RBX: ffffc9000478efd8 RCX: 0000000000080000
RDX: ffffc9000f4da000 RSI: 0000000000000c35 RDI: 0000000000000c36
RBP: 0000000000000000 R08: ffffffff8fa10ef7 R09: 1ffffffff1f421de
R10: dffffc0000000000 R11: ffffffff81679c10 R12: 184898a57a6335ad
R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f0656dd56c0(0000) GS:ffff888125d52000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000010000 CR3: 000000006029c000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
taprio_change+0x2da5/0x3f60 net/sched/sch_taprio.c:1938
taprio_init+0x959/0xbd0 net/sched/sch_taprio.c:2112
qdisc_create+0x7ac/0xea0 net/sched/sch_api.c:1333
__tc_modify_qdisc net/sched/sch_api.c:1758 [inline]
tc_modify_qdisc+0x1426/0x2010 net/sched/sch_api.c:1822
rtnetlink_rcv_msg+0x779/0xb70 net/core/rtnetlink.c:6953
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2534
netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
netlink_unicast+0x75b/0x8d0 net/netlink/af_netlink.c:1339
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1883
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x21c/0x270 net/socket.c:727
____sys_sendmsg+0x505/0x830 net/socket.c:2566
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
__sys_sendmsg net/socket.c:2652 [inline]
__do_sys_sendmsg net/socket.c:2657 [inline]
__se_sys_sendmsg net/socket.c:2655 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2655
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0658f8e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0656dd5038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f06591b6160 RCX: 00007f0658f8e929
RDX: 0000000000000000 RSI: 00002000000007c0 RDI: 000000000000000e
RBP: 00007f0659010b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f06591b6160 R15: 00007ffc8579ea48
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Takamitsu Iwai]

I found validation does not work properly when link speed is large.
picos_per_byte becomes too small when link speed is large, and
length_to_duration(q, ETH_ZLEN) becomes zero. This results in failing
validation in fill_sched_entry() and parse_taprio_schedule(), and any
entry->interval and cycle_time are permitted.

picos_per_byte should be larger than 16 because ETH_ZLEN (60) *
&q->picos_per_byte should be larger than PSEC_PER_NSEC=1000.

This report seems to be related this, so let me check the following patch
resolve the issue.

#syz test

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 2b14c81a87e5..b0a5bd1c9995 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -43,6 +43,11 @@ static struct static_key_false taprio_have_working_mqprio;
#define TAPRIO_SUPPORTED_FLAGS \
(TCA_TAPRIO_ATTR_FLAG_TXTIME_ASSIST | TCA_TAPRIO_ATTR_FLAG_FULL_OFFLOAD)
#define TAPRIO_FLAGS_INVALID U32_MAX
+/* picos_per_byte should be larger than 16 since duration for minimum ethernet
+ * frame should not be zero.
+ */
+#define TAPRIO_PICOS_PER_BYTE_MIN 17
+

struct sched_entry {
/* Durations between this GCL entry and the GCL entry where the
@@ -1299,7 +1304,7 @@ static void taprio_set_picos_per_byte(struct net_device *dev,
speed = ecmd.base.speed;

skip:
- picos_per_byte = (USEC_PER_SEC * 8) / speed;
+ picos_per_byte = max((USEC_PER_SEC * 8) / speed, TAPRIO_PICOS_PER_BYTE_MIN);

atomic64_set(&q->picos_per_byte, picos_per_byte);
netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: %d\n",

[syzbot]

> I found validation does not work properly when link speed is large.
> picos_per_byte becomes too small when link speed is large, and
> length_to_duration(q, ETH_ZLEN) becomes zero. This results in failing
> validation in fill_sched_entry() and parse_taprio_schedule(), and any
> entry->interval and cycle_time are permitted.
>
> picos_per_byte should be larger than 16 because ETH_ZLEN (60) *
> &q->picos_per_byte should be larger than PSEC_PER_NSEC=1000.
>
> This report seems to be related this, so let me check the following patch
> resolve the issue.
>
> #syz test

This crash does not have a reproducer. I cannot test it.