netdev - Re: [RFC net] net: stream: don't purge sk_error

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: <20210914110315.32ebccce@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 14 Sep 2021 11:03:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     willemb@...gle.com, netdev@...r.kernel.org
Subject: Re: [RFC net] net: stream: don't purge sk_error_queue without
 holding its lock

On Tue, 14 Sep 2021 10:55:49 -0700 Eric Dumazet wrote:
> On 9/14/21 9:56 AM, Jakub Kicinski wrote:
> > Right, but then inet_sock_destruct() also purges the err queue, again.
> > I was afraid of regressions but we could just remove the purging 
> > from sk_stream_kill_queues(), and target net-next?
> >   
> 
> Yes, this would be the safest thing.

Alright, let me do more testing and post a removal to net-next.

> >> If you think there is a bug, it must be fixed in another way.
> >>
> >> IMO, preventing err packets from a prior session being queued after a tcp_disconnect()
> >> is rather hard. We should not even try (packets could be stuck for hours in a qdisc)  
> > 
> > Indeed, we could rearrange the SOCK_DEAD check in sock_queue_err_skb()
> > to skip queuing and put it under the err queue lock (provided we make
> > sk_stream_kill_queues() take that lock as well). But seems like an
> > overkill. I'd lean towards the existing patch or removing the purge from
> > sk_stream_kill_queues(). LMK what you prefer, this is not urgent.
> 
> The issue would really about the tcp_disconnect() case, 
> followed by a reuse of the socket to establish another session.
> 
> In order to prevent polluting sk_error_queue with notifications
> triggered by old packets (from prior flow), this would require
> to record the socket cookie in skb, or something like that :/

Ah, I see what you meant! I'll make a note of the disconnect case 
in the commit message. I just care that we don't corrupt the queue
on close.