In the Linux kernel, the following vulnerability has been resolved: sctp: add a refcnt in sctpstreampriorities to avoid a nested loop With this refcnt added in sctpstreampriorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctpschedpriofreesid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctpschedpriofreesid+0xab/0x100 [sctp] sctpstreamfreeext+0x64/0xa0 [sctp] sctpstreamfree+0x31/0x50 [sctp] sctpassociationfree+0xa5/0x200 [sctp] Note that it doesn't need to use refcountt type for this counter, as its accessing is always protected under the sock lock. v1->v2: - add a check in sctpschedprioset to avoid the possible priohead refcnt overflow.