linux-kernel - Re: [REGRESSION] 6.14.3 panic - kernel NULL pointer dereference in htb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250422214716.5e181523@frodo.int.wylie.me.uk>
Date: Tue, 22 Apr 2025 21:47:16 +0100
From: "Alan J. Wylie" <alan@...ie.me.uk>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Holger Hoffstätte <holger@...lied-asynchrony.com>,
 Jamal Hadi Salim <jhs@...atatu.com>, regressions@...ts.linux.dev, Jiri
 Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, Octavian Purdila <tavip@...gle.com>, Toke
 Høiland-Jørgensen <toke@...hat.com>,
 stable@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [REGRESSION] 6.14.3 panic - kernel NULL pointer dereference in
 htb_dequeue

On Tue, 22 Apr 2025 13:42:19 -0700
Cong Wang <xiyou.wangcong@...il.com> wrote:

> On Tue, Apr 22, 2025 at 07:20:24PM +0200, Holger Hoffstätte wrote:
> > (cc: Greg KH)
> > 
> > On 2025-04-22 18:51, Alan J. Wylie wrote:  
> > > On Mon, 21 Apr 2025 21:09:27 +0100
> > > "Alan J. Wylie" <alan@...ie.me.uk> wrote:
> > >   
> > > > On Mon, 21 Apr 2025 21:47:44 +0200
> > > > Holger Hoffstätte <holger@...lied-asynchrony.com> wrote:
> > > >   
> > > > > > I'm afraid that didn't help. Same panic.  
> > > > > 
> > > > > Bummer :-(
> > > > > 
> > > > > Might be something else missing then - so for now the only
> > > > > other thing I'd suggest is to revert the removal of the qlen
> > > > > check in fq_codel.  
> > > > 
> > > > Like this?
> > > > 
> > > > $ git diff  sch_fq_codel.c
> > > > diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> > > > index 6c9029f71e88..4fdf317b82ec 100644
> > > > --- a/net/sched/sch_fq_codel.c
> > > > +++ b/net/sched/sch_fq_codel.c
> > > > @@ -316,7 +316,7 @@ static struct sk_buff
> > > > *fq_codel_dequeue(struct Qdisc *sch) qdisc_bstats_update(sch,
> > > > skb); flow->deficit -= qdisc_pkt_len(skb);
> > > > -       if (q->cstats.drop_count) {
> > > > +       if (q->cstats.drop_count && sch->q.qlen) {
> > > >                  qdisc_tree_reduce_backlog(sch,
> > > > q->cstats.drop_count, q->cstats.drop_len);
> > > >                  q->cstats.drop_count = 0;
> > > > $
> > > >   
> > > 
> > > It's been about 21 hours and no crash yet. I had an excellent day
> > > down a cave, so there's not been as much Internet traffic as
> > > usual, but there's a good chance the above patch as at least
> > > worked around, if not fixed the issue.  
> > 
> > Thought so .. \o/
> > 
> > I guess now the question is what to do about it. IIUC the fix
> > series [1] addressed some kind of UAF problem, but obviously was
> > not applied correctly or is missing follow-ups. It's also a bit
> > mysterious why adding the HTB patch didn't work.
> > 
> > Maybe Cong Wang can advise what to do here?  
> 
> I guess my patch caused some regression, I am still decoding the
> crashes reported here.
> 
> Meanwhile, if you could provide a reliable (and ideally minimum)
> reproducer, it would help me a lot to debug.
> 
> Thanks!

Sorry. No reproducer. The crashes seemed to be totally random.

I posted the script I use to set up tc in my initial report.

FYI, here's the resulting config.

# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2 
qdisc fq_codel 0: dev enp3s0 root refcnt 2 limit 10240p flows 1024 quantum 6014 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: dev enp4s0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: dev enp5s6f0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc noqueue 0: dev wlp5s7 root refcnt 2 
qdisc noqueue 0: dev brdmz root refcnt 2 
qdisc noqueue 0: dev heipv6 root refcnt 2 
qdisc fq_codel 0: dev tun0 root refcnt 2 limit 10240p flows 1024 quantum 1464 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc htb 1: dev ppp0 root refcnt 2 r2q 10 default 0x11 direct_packets_stat 0 direct_qlen 3
qdisc fq_codel 824c: dev ppp0 parent 1:11 limit 10240p flows 1024 quantum 300 target 5ms interval 100ms memory_limit 32Mb drop_batch 64 
qdisc ingress ffff: dev ppp0 parent ffff:fff1 ---------------- 
qdisc fq_codel 0: dev tun1 root refcnt 2 limit 10240p flows 1024 quantum 1500 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc htb 1: dev ppp0ifb0 root refcnt 2 r2q 20 default 0x11 direct_packets_stat 0 direct_qlen 32
qdisc fq_codel 824b: dev ppp0ifb0 parent 1:11 limit 10240p flows 1024 quantum 300 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
# 



-- 
Alan J. Wylie     https://www.wylie.me.uk/     mailto:<alan@...ie.me.uk>

Dance like no-one's watching. / Encrypt like everyone is.
Security is inversely proportional to convenience