Patch "net/sched: sch_qfq: account for stab overhead in qfq_enqueue" has been added to the 6.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    net/sched: sch_qfq: account for stab overhead in qfq_enqueue

to the 6.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     net-sched-sch_qfq-account-for-stab-overhead-in-qfq_e.patch
and it can be found in the queue-6.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 6a853a023604a3d01a17866ce9b4d5a5355edc97
Author: Pedro Tammela <pctammela@xxxxxxxxxxxx>
Date:   Tue Jul 11 18:01:02 2023 -0300

    net/sched: sch_qfq: account for stab overhead in qfq_enqueue
    
    [ Upstream commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 ]
    
    Lion says:
    -------
    In the QFQ scheduler a similar issue to CVE-2023-31436
    persists.
    
    Consider the following code in net/sched/sch_qfq.c:
    
    static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch,
                    struct sk_buff **to_free)
    {
         unsigned int len = qdisc_pkt_len(skb), gso_segs;
    
        // ...
    
         if (unlikely(cl->agg->lmax < len)) {
             pr_debug("qfq: increasing maxpkt from %u to %u for class %u",
                  cl->agg->lmax, len, cl->common.classid);
             err = qfq_change_agg(sch, cl, cl->agg->class_weight, len);
             if (err) {
                 cl->qstats.drops++;
                 return qdisc_drop(skb, sch, to_free);
             }
    
        // ...
    
         }
    
    Similarly to CVE-2023-31436, "lmax" is increased without any bounds
    checks according to the packet length "len". Usually this would not
    impose a problem because packet sizes are naturally limited.
    
    This is however not the actual packet length, rather the
    "qdisc_pkt_len(skb)" which might apply size transformations according to
    "struct qdisc_size_table" as created by "qdisc_get_stab()" in
    net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc.
    
    A user may choose virtually any size using such a table.
    
    As a result the same issue as in CVE-2023-31436 can occur, allowing heap
    out-of-bounds read / writes in the kmalloc-8192 cache.
    -------
    
    We can create the issue with the following commands:
    
    tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \
    overhead 999999999 linklayer ethernet qfq
    tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k
    tc filter add dev $DEV parent 1: matchall classid 1:1
    ping -I $DEV 1.1.1.2
    
    This is caused by incorrectly assuming that qdisc_pkt_len() returns a
    length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX.
    
    Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
    Reported-by: Lion <nnamrec@xxxxxxxxx>
    Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>
    Signed-off-by: Jamal Hadi Salim <jhs@xxxxxxxxxxxx>
    Signed-off-by: Pedro Tammela <pctammela@xxxxxxxxxxxx>
    Reviewed-by: Simon Horman <simon.horman@xxxxxxxxxxxx>
    Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 63a5b277c117f..befaf74b33caa 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -381,8 +381,13 @@ static int qfq_change_agg(struct Qdisc *sch, struct qfq_class *cl, u32 weight,
 			   u32 lmax)
 {
 	struct qfq_sched *q = qdisc_priv(sch);
-	struct qfq_aggregate *new_agg = qfq_find_agg(q, lmax, weight);
+	struct qfq_aggregate *new_agg;
 
+	/* 'lmax' can range from [QFQ_MIN_LMAX, pktlen + stab overhead] */
+	if (lmax > QFQ_MAX_LMAX)
+		return -EINVAL;
+
+	new_agg = qfq_find_agg(q, lmax, weight);
 	if (new_agg == NULL) { /* create new aggregate */
 		new_agg = kzalloc(sizeof(*new_agg), GFP_ATOMIC);
 		if (new_agg == NULL)



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux