BUG: "hc->tx_t_ipi == NUM" holds (exception!) at net/dccp/ccids/ccid3.c:LINE/ccid3_update_send_interval()

Dear Maintainers,

When using our customized Syzkaller to fuzz the latest Linux kernel, the =
following crash (79th)
was triggered.

HEAD commit: d082ecbc71e9e0bf49883ee4afd435a77a5101b6
git tree: upstream
Output: =
https://github.com/pghk13/Kernel-Bug/blob/main/0225_6.14rc2/79-BUG_%20hc-_=
tx_t_ipi%20%3D%3D%20NUM%20holds%20(exception!)%20at%20net_dccp_ccids_ccid3=
.c_LINE_ccid3_update_send_interval()/log0
Kernel config: =
https://github.com/pghk13/Kernel-Bug/blob/main/0225_6.14rc2/config_6.14rc4=
.txt
C reproducer: =
https://github.com/pghk13/Kernel-Bug/blob/main/0225_6.14rc2/79-BUG_%20hc-_=
tx_t_ipi%20%3D%3D%20NUM%20holds%20(exception!)%20at%20net_dccp_ccids_ccid3=
.c_LINE_ccid3_update_send_interval()/repro.cprog
Syzlang reproducer: =
https://github.com/pghk13/Kernel-Bug/blob/main/0225_6.14rc2/79-BUG_%20hc-_=
tx_t_ipi%20%3D%3D%20NUM%20holds%20(exception!)%20at%20net_dccp_ccids_ccid3=
.c_LINE_ccid3_update_send_interval()/repro.prog

The problem is caused by an invalid calculation of the send interval =
(hc->tx_t_ipi) in the DCCP CCID3 congestion control module, where =
hc->tx_t_ipi =3D 0 violates the protocol logic. The problem is triggered =
(possibly) by the interaction of the following parameters in the system =
call sequence:

1.One possibility is that the initial packet is too large (sendto$inet, =
len=3D0xffc3)
This updates hc->tx_s to a larger value via ccid3_hc_tx_update_s, but =
subsequent small packets (e.g., sendmsg$inet with len=3D1) reduce =
hc->tx_s exponentially via the EWMA filter.

2.Another possibility is an unusually high send rate (hc->tx_x)
setsockopt or initial network conditions (e.g., RTT close to zero) may =
configure an excessively large hc->tx_x, causing scaled_div32((tx_s << =
6), tx_x) to truncate to zero. The problem can be reliably reproduced =
using the provided system call sequence. We suspect that validation of =
tx_s or tx_x lower bounds is missing from the TFRC rate calculation.

Our knowledge of the kernel is somewhat limited, and we'd appreciate it =
if you could determine if there is such an issue. If this issue doesn't =
have an impact, please ignore it =E2=98=BA.

If you fix this issue, please add the following tag to the commit:
Reported-by: Kun Hu <[email protected]>, Jiaji Qin =
<[email protected]>, Shuoran Bai <[email protected]>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
BUG: "hc->tx_t_ipi =3D=3D 0" holds (exception!) at =
net/dccp/ccids/ccid3.c:90/ccid3_update_send_interval()
CPU: 1 UID: 0 PID: 9488 Comm: syz-executor236 Not tainted 6.14.0-rc4 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS =
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x180/0x1b0
 ccid3_update_send_interval+0x188/0x1c0
 ccid3_hc_tx_packet_sent+0x132/0x190
 dccp_xmit_packet+0x278/0x710
 dccp_write_xmit+0x174/0x1d0
 dccp_sendmsg+0xadd/0xcb0
 inet_sendmsg+0x121/0x150
 __sock_sendmsg+0x1c3/0x2a0
 ____sys_sendmsg+0x74c/0xa30
 ___sys_sendmsg+0x11d/0x1c0
 __sys_sendmsg+0x151/0x200
 do_syscall_64+0xcf/0x250
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe5a5d9bb7d
Code: c3 e8 37 2a 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 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 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc6a60bfd8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007fe5a5d9bb7d
RDX: 0000000000000000 RSI: 00000000200004c0 RDI: 0000000000000004
RBP: 0000000000000000 R08: 00000000a5d54bd0 R09: 00000000a5d54bd0
R10: 00000000a5d54bd0 R11: 0000000000000246 R12: 00007ffc6a60bfe4
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
---------------
thanks,
Kun Hu=