PT-2026-121927
CVE-2026-98955
·
تاريخ النشر
2026-10-23
·
تاريخ التحديث
2026-10-23
الوصف من
الدرجة
N/A
غير متوفرلا تتوفر حاليًا تقييمات أو مقاييس للخطورة. سنحدّث المعلومات المقابلة في الصفحة فور توفرها.
In the Linux kernel, the following vulnerability has been resolved:
flow dissector: avoid u16 truncation of skb->len when computing thoff
skb flow dissect() computes key control->thoff using:
key control->thoff = min t(u16, nhoff, skb ? skb->len : hlen);
min t(u16, ...) casts both arguments to u16 before comparing them.
Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the
truncated length wins and thoff is set to a bogus small value, even
when the dissection succeeded. For example, an IPv4/TCP frame with
skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as
skb probe transport header() point the transport header inside the
Ethernet header.
Such skbs are not exotic:
- At the time of commit d0c081b49137 ("flow dissector: properly cap thoff field"), AF PACKET with PACKET VNET HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc skb with frags() accepted up to MAX SKB FRAGS (17) order-0 pages on top of the linear part).
- BIG TCP now makes skbs larger than 64KB common.
- The following patch makes tun get user() dissect IFF TAP frames before eth type trans() pulls the Ethernet header, so a GSO frame carrying a 65522..65535 byte L3 packet will be dissected with skb->len in [65536, 65549].
Compare as u32 instead. If the resulting offset cannot be represented
in the u16 key control->thoff, cap it to U16 MAX and report the
dissection as failed rather than silently returning a wrong transport
offset. thoff is still set on failure, as some callers (such as
eth get headlen()) use it regardless of the return value.
وجدت خطأً في الوصف؟ لديك ما تضيفه؟ لا تتردد في مراسلتنا 👾