---------- Forwarded message ---------
From: Yun Levi <[email protected]>
Date: Mon, Mar 30, 2020 at 3:01 PM
Subject: Some happening when using BIND mount with network namespace.
To: Alexander Viro <[email protected]>, David S. Miller
<[email protected]>, Jakub Kicinski <[email protected]>, Guillaume
Nault <[email protected]>, Nicolas Dichtel
<[email protected]>, Eric Dumazet <[email protected]>, David
Howells <[email protected]>, Thomas Gleixner <[email protected]>,
Li RongQing <[email protected]>, Johannes Berg
<[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>
Hello. I'm Levi who is the beginner of Linux kernel.
When I use system calls related to network namespace, I got a some
problem in below scenario.
That's why I want to distinguish it's prohibit case for using unshare
and setns system call.
1. Forking the process.
2. [PARENT] Waiting the Child till the end.
3. [CHILD] unshare for creating new network namespace
4. [CHILD] Bind mount /proc/self/ns/net to some mount point.
5. [CHILD] Exit child.
6. [PARENT] Try to setns with binded mount point
In my analysis I confirm step 4 to 6 makes problem.
When we try to bind network namespace, it doesn't increase reference
count of related network namespace which saved on inode->i_private.
That's why network namespace made by unshare system call will be free on Step 5.
But on bind mountpoint, it still has network namespace pointer that was freed.
This makes some memory corruption on kernel when someone require to
allocate memory and give the pointer which allocated to the network
namespace made by Step 3.
That's why I can see the some Kernel Panic when I kill the some process...
So I attach some patch file to fix this problem.
But I want to distinguish it abnormal usage or not and this patch
should be applied.
Thank you for reading.
HTH.
Levi.