ACK: [SRU][N][PATCH v2 0/1] CVE-2024-56770

[Kuba Pawlak]

On 11.04.2025 20:08, Tim Whisonant wrote:
> SRU Justification:
>
> [Impact]
>
> net/sched: netem: account for backlog updates from child qdisc
>
> In general, 'qlen' of any classful qdisc should keep track of the
> number of packets that the qdisc itself and all of its children holds.
> In case of netem, 'qlen' only accounts for the packets in its internal
> tfifo. When netem is used with a child qdisc, the child qdisc can use
> 'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
> or dropped SKBs. This function updates 'qlen' and the backlog statistics
> of netem, but netem does not account for changes made by a child qdisc.
> 'qlen' then indicates the wrong number of packets in the tfifo.
> If a child qdisc creates new SKBs during enqueue and informs its parent
> about this, netem's 'qlen' value is increased. When netem dequeues the
> newly created SKBs from the child, the 'qlen' in netem is not updated.
> If 'qlen' reaches the configured sch->limit, the enqueue function stops
> working, even though the tfifo is not full.
>
> Reproduce the bug:
> Ensure that the sender machine has GSO enabled. Configure netem as root
> qdisc and tbf as its child on the outgoing interface of the machine
> as follows:
> $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100
> $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms
>
> Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
> client on the machine. Check the qdisc statistics:
> $ tc -s qdisc show dev <oif>
>
> Statistics after 10s of iPerf3 TCP test before the fix (note that
> netem's backlog > limit, netem stopped accepting packets):
> qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
>   Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
>   backlog 4294528236b 1155p requeues 0
> qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
>   Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
>   backlog 0b 0p requeues 0
>
> Statistics after the fix:
> qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
>   Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
>   Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
>   backlog 0b 0p requeues 0
>
> tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
> The interface fully stops transferring packets and "locks". In this case,
> the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
> its limit and no more packets are accepted.
>
> This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
> only decreased when a packet is returned by its dequeue function, and not
> during enqueuing into the child qdisc. External updates to 'qlen' are thus
> accounted for and only the behavior of the backlog statistics changes. As
> in other qdiscs, 'qlen' then keeps track of  how many packets are held in
> netem and all of its children. As before, sch->limit remains as the
> maximum number of packets in the tfifo. The same applies to netem's
> backlog statistics.
>
> [Fix]
>
> Oracular: not affected
> Noble:    cherry picked from upstream
> Jammy:    not affected
> Focal:    not affected
> Bionic:   not affected
> Xenial:   not affected
> Trusty:   not affected
>
> [Test Plan]
>
> Compile tested only.
>
> [Where problems could occur]
>
> This fix affects those who use a classful queueing discipline with the
> network emulator (NETEM) module. An issue with this fix would be visible
> to the user as unexpected networking behavior which could lead to the
> packet queue locking up.
>
> [Notes]
>
> v2 - upon examining v1, it was noticed that the commit in question had
> already been applied to O/J/F. As such, v2 targets only N.
>
> Martin Ottens (1):
>    net/sched: netem: account for backlog updates from child qdisc
>
>   net/sched/sch_netem.c | 2 ++
>   1 file changed, 2 insertions(+)
>
Acked-by: Kuba Pawlak <kuba.pawlak at canonical.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x216A9D7E3B63DCB4.asc
Type: application/pgp-keys
Size: 3139 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250413/7fde5406/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250413/7fde5406/attachment.sig>