From: Simon Horman <horms@kernel.org>
To: "Kito Xu (veritas501)" <hxzene@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/sched: sch_dualpi2: fix NULL pointer dereference in dualpi2_change()
Date: Tue, 14 Apr 2026 19:36:01 +0100 [thread overview]
Message-ID: <20260414183601.GD772670@horms.kernel.org> (raw)
In-Reply-To: <20260414183132.GC772670@horms.kernel.org>
On Tue, Apr 14, 2026 at 07:31:32PM +0100, Simon Horman wrote:
> On Mon, Apr 13, 2026 at 03:57:40PM +0800, Kito Xu (veritas501) wrote:
> > dualpi2_change() uses a trim loop to enforce the new queue limit after a
> > configuration change. The loop calls qdisc_dequeue_internal(sch, true)
> > which only dequeues from the C-queue (sch->q) and the requeue list
> > (sch->gso_skb). It does not dequeue from the L-queue (q->l_queue).
> >
> > However, the loop continuation condition checks qdisc_qlen(sch), which
> > reflects the total packet count across both queues because
> > dualpi2_enqueue_skb() manually increments sch->q.qlen for L-queue
> > packets (line 418). Similarly, q->memory_used accounts for memory from
> > both queues.
> >
> > When all packets reside in the L-queue and the C-queue is empty, the
> > loop condition remains true but qdisc_dequeue_internal() returns NULL.
> > The subsequent skb->truesize dereference causes a NULL pointer oops.
> >
> > An unprivileged user can trigger this from a user namespace:
> >
> > 1. unshare(CLONE_NEWUSER | CLONE_NEWNET)
> > 2. Create a dummy device and attach dualpi2 qdisc
> > 3. Send ECT(1)-marked packets to fill the L-queue
> > 4. Reduce the qdisc limit via RTM_NEWQDISC
>
> ...
>
> > Fix this by adding a NULL check after qdisc_dequeue_internal(). When
> > the C-queue is exhausted but L-queue packets keep qdisc_qlen(sch) above
> > the limit, the loop breaks safely. Remaining excess L-queue packets will
> > be drained by the normal dequeue path.
> >
> > Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc")
> > Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Sorry, I now see that a more comprehensive fix for this code path
is available from the original author of the code.
- [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
https://lore.kernel.org/all/20260413163711.56191-1-chia-yu.chang@nokia-bell-labs.com/
next prev parent reply other threads:[~2026-04-14 18:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 7:57 [PATCH] net/sched: sch_dualpi2: fix NULL pointer dereference in dualpi2_change() Kito Xu (veritas501)
2026-04-14 18:31 ` Simon Horman
2026-04-14 18:36 ` Simon Horman [this message]
2026-04-15 2:31 ` veritas501
2026-04-15 12:34 ` Simon Horman
2026-04-15 12:37 ` Chia-Yu Chang (Nokia)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260414183601.GD772670@horms.kernel.org \
--to=horms@kernel.org \
--cc=chia-yu.chang@nokia-bell-labs.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hxzene@gmail.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.