summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorPaolo Abeni <pabeni@redhat.com>2026-08-25 13:09:34 +0200
committerPaolo Abeni <pabeni@redhat.com>2026-08-25 13:09:35 +0200
commita687f2ae995fc366a6f2ef180451e6db4c6b4530 (patch)
tree3a70ded8205fefedaa84d46087cb2c9da3c697f4 /include
parent728836ebca239810f164262b10211ef59182f811 (diff)
parent816e90057ab1879562a5b7cc688e35bb9027ae97 (diff)
downloadlinux-a687f2ae995fc366a6f2ef180451e6db4c6b4530.tar.gz
linux-a687f2ae995fc366a6f2ef180451e6db4c6b4530.zip
Merge branch 'net-sched-fix-quantum-mtu-overflow-in-fq-fq_codel-sch_codel-fq_pie-hhf-sfq'
Jamal Hadi Salim says: ==================== net: sched: fix quantum/mtu overflow in fq, fq_codel, sch_codel, fq_pie, hhf, sfq Several qdiscs derive their per-flow quantum or CoDel mtu from psched_mtu() without an overflow or zero clamp, which can drive the dequeue/credit-refill loop into a soft lockup or silently disable the AQM. vega@nebusec.ai provided reports and PoCs for the following qdiscs: sch_fq, sch_fq_codel, sch_fq_pie, sch_hhf, and sch_sfq. sch_codel was found by inspection for the same pattern. It's TheLinuxWay (i.e cutnpaste code from somewhere for your new feature) and the AIs are having a lot of fun finding patterns. We must overcome! Clamp the quantum (and, for the codel family, the cparams/params mtu) to a sane range at init/change time so the dequeue loops terminate and the AQM stays armed. The clamps live in the init/change paths, not the per-packet fast path, so no hot-path cost is added for a configuration issue. This series depends on "net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", which caps qdisc_pkt_len() at GSO_MAX_SIZE in __qdisc_calculate_pkt_len(). That cap closes the fq_codel TCA_STAB backlog-wrap vector (qdisc_pkt_len inflated to ~1 GiB wrapping the u32 per-flow backlog to 0 and NULL-derefing in fq_codel_drop()); with it upstream this series no longer needs the fq_codel_drop() hardening hunk that the earlier respin carried. The five quantum/mtu fixes here are psched_mtu()-driven and orthogonal to the qdisc_pkt_len() cap. Q: Why not bound the MTU at the source instead? dummy's max_mtu == 0 is intentional (dev_validate_mtu() treats 0 as unbounded), other drivers can legitimately advertise large MTUs, and qdiscs must not trust psched_mtu() regardless. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps 2 * psched_mtu() or psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting a huge MTU). Requires CAP_NET_ADMIN in a user namespace. ==================== Link: https://patch.msgid.link/20260822195509.112717-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions