netdev - Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

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]

Date:   Thu, 1 Feb 2018 20:02:07 +0200
From:   Tommi Rantala <tt.rantala@...il.com>
To:     Tommi Rantala <tommi.t.rantala@...ia.com>
Cc:     Neil Horman <nhorman@...driver.com>,
        Vlad Yasevich <vyasevich@...il.com>,
        linux-sctp@...r.kernel.org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Subject: Re: sctp netns "unregister_netdevice: waiting for lo to become free.
 Usage count = 1"

2018-01-31 19:51 GMT+02:00 Tommi Rantala <tommi.t.rantala@...ia.com>:
> On 31.01.2018 14:31, Neil Horman wrote:
>>
>> On Wed, Jan 31, 2018 at 11:42:24AM +0200, Tommi Rantala wrote:
>>>
>>> I think there's a problem in the dst refcounting in sctp_v4_get_dst()
>>>
>>> There's a dst_entry struct that has >0 refcnt after running the testcase,
>>> which makes it impossible to delete the loopback device, as that dst is
>>> never freed.
>>>
>>> I'll try to make a patch.
>>>
>> Are you looking at the second for loop there, which uses
>> ip_route_output_key,
>> but discards the result if dst is already set?  That does look a bit
>> wonky, and
>> the same problem may exist in the ipv6 path.  Let me know what the result
>> is.
>
>
> Yes, that was it. Did you receive the email I sent with the patch?
> (I'm not seeing that message e.g. at spinics.net linux-sctp archive, so just
> wondering if that email got lost somehow...)
>
> I'll check the ipv6 case, did not try it yet.
>
> Tommi

As far as I can tell, the ipv6 code does not suffer from this.
The dst handling there looks good to me.

Tommi