netdev - Re: [PATCH net] net: netem: fix use after free and double free with packet corruption

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] [day] [month] [year] [list]

Message-ID: <20190615132507.49589073@cakuba.netronome.com>
Date:   Sat, 15 Jun 2019 13:25:07 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     David Miller <davem@...emloft.net>
Cc:     stephen@...workplumber.org, jhs@...atatu.com,
        xiyou.wangcong@...il.com, jiri@...nulli.us,
        netem@...ts.linux-foundation.org, netdev@...r.kernel.org,
        oss-drivers@...ronome.com, edumazet@...gle.com, posk@...gle.com
Subject: Re: [PATCH net] net: netem: fix use after free and double free with
 packet corruption

On Fri, 14 Jun 2019 19:08:08 -0700 (PDT), David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Date: Wed, 12 Jun 2019 11:51:21 -0700
> 
> > Brendan reports that the use of netem's packet corruption capability
> > leads to strange crashes.  This seems to be caused by
> > commit d66280b12bd7 ("net: netem: use a list in addition to rbtree")
> > which uses skb->next pointer to construct a fast-path queue of
> > in-order skbs.
> > 
> > Packet corruption code has to invoke skb_gso_segment() in case
> > of skbs in need of GSO.  skb_gso_segment() returns a list of
> > skbs.  If next pointers of the skbs on that list do not get cleared
> > fast path list goes into the weeds and tries to access the next
> > segment skb multiple times.
> > 
> > Reported-by: Brendan Galloway <brendan.galloway@...ronome.com>
> > Fixes: d66280b12bd7 ("net: netem: use a list in addition to rbtree")
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> > Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@...ronome.com>  
> 
> Please rework the commit message a bit to make things cleared, your
> ascii diagrams would be great. :)

In process of rewriting the commit message I found a memory leak,
and the backlog accounting is also buggy in the segmentation path

qdisc netem 8001: root refcnt 64 limit 100 delay 19us corrupt 1%
 Sent 30237896 bytes 19895 pkt (dropped 1885, overlimits 0 requeues 287)
 backlog 0b 99p requeues 287
         ^^^^^^
         99 packets but 0 bytes

I need an internal review, and will repost soon.  I need to stop looking
for bugs here 🙈