Re: [PATCH 2/2] net/sched: sch_cake: check negative transport offset in cake_overhead()
From: Yuchao Zhang <hidden>
Date: 2026-09-22 08:41:25
Also in:
lkml, stable
Hi, Thank you for the detailed review. All three points raised are valid and insightful. 1. Regarding OOB read vs shaper accounting corruption (Severity: Medium): You are completely right. While the negative offset in [PATCH 1/2] (net/core/dev.c) directly causes a wild pointer dereference via raw pointer arithmetic (skb->data + hdr_len), in [PATCH 2/2] cake_overhead() passes hdr_len to skb_header_pointer() which undoes the unsigned conversion. The real impact is corrupted header length accounting and inflated shaper durations, not an out-of-bounds read past the slab allocation. I have revised the commit message to accurately describe the issue. 2. Regarding companion guard from qdisc_pkt_len_segs_init() (Severity: Medium): Agreed. When the transport header was never set, skb_transport_offset() returns ~65535, which bypasses a negative offset check and inflates the shaper duration to ~66 KB per segment. In v2, I have imported the companion !skb_transport_header_was_set(skb) check. 3. Regarding segs == 0 underflow in multi-segment arithmetic (Severity: High): Agreed. When segs == 0 (e.g. from DODGY GSO frames), (segs - 1) underflows to 4294967295, causing an astronomical duration to be charged in cake_advance_shaper() and permanently stalling dequeues. In v2, I have updated the check to `segs <= 1`. v2 patch has been sent in reply to this thread. pw-bot: cr