netdev - Re: setns() affecting other threads in 5.10.132 and 6.0 #forregzbot

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]

Date:   Thu, 29 Sep 2022 11:33:45 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: setns() affecting other threads in 5.10.132 and 6.0 #forregzbot

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

On 06.09.22 12:48, David Laight wrote:
> From: Alexey Dobriyan
>> Sent: 05 September 2022 18:33
>>>> -----Original Message-----
>>>> From: David Laight <David.Laight@...LAB.COM>
>>>> Sent: 04 September 2022 15:05
>>>>
>>>> Sometime after 5.10.105 (5.10.132 and 6.0) there is a change that
>>>> makes setns(open("/proc/1/ns/net")) in the main process changes
>>>> the behaviour of other process threads.
>>
>> Not again...
> 
> I've realised what is going on.
> It really isn't obvious at all.
> Quite possibly the last change did fix it - even though
> it broke our code.

In that case this seems to be appropriate, unless I misunderstood things:

#regzbot invalid: apparently not a regression

> /proc/net is a symlink to /proc/self/net.
> But that isn't what the code wants to open.
> What it needs is /proc/self/task/self/net.
> But there isn't a 'self' in /proc/self/task.
> Which makes it all a bit tedious (especially without gettid() in glibc).
> (This is a busybox/buildroot system, maybe I could add it!)
> 
> I'd probably have noticed earlier if the /proc/net
> symlink didn't exist.
> I guess that is for compatibility with pre-netns kernels.
> 
> 	David