Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]tcp: Correct signedness in skb remaining space calculation[EOL][EOL]Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow.[EOL][EOL]When we send data, if an skb exists at the tail of the write queue, the[EOL]kernel will attempt to append the new data to that skb. However, the code[EOL]that checks for available space in the skb is flawed:[EOL]'''[EOL]copy = size_goal - skb->len[EOL]'''[EOL][EOL]The types of the variables involved are:[EOL]'''[EOL]copy: ssize_t (s64 on 64-bit systems)[EOL]size_goal: int[EOL]skb->len: unsigned int[EOL]'''[EOL][EOL]Due to C's type promotion rules, the signed size_goal is converted to an[EOL]unsigned int to match skb->len before the subtraction. The result is an[EOL]unsigned int.[EOL][EOL]When this unsigned int result is then assigned to the s64 copy variable,[EOL]it is zero-extended, preserving its non-negative value. Consequently, copy[EOL]is always >= 0.[EOL][EOL]Assume we are sending 2GB of data and size_goal has been adjusted to a[EOL]value smaller than skb->len. The subtraction will result in copy holding a[EOL]very large positive integer. In the subsequent logic, this large value is[EOL]used to update sk->sk_forward_alloc, which can easily cause it to overflow.[EOL][EOL]The syzkaller reproducer uses TCP_REPAIR to reliably create this[EOL]condition. However, this can also occur in real-world scenarios. The[EOL]tcp_bound_to_half_wnd() function can also reduce size_goal to a small[EOL]value. This would cause the subsequent tcp_wmem_schedule() to set[EOL]sk->sk_forward_alloc to a value close to INT_MAX. Further memory[EOL]allocation requests would then cause sk_forward_alloc to wrap around and[EOL]become negative.[EOL][EOL][1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

CREATE(Triage):(User=admin) [CVE-2025-38463 (https://nvd.nist.gov/vuln/detail/CVE-2025-38463)