---------- Forwarded message --------- From: Yun Levi <ppbuk5246@xxxxxxxxx> Date: Mon, Mar 30, 2020 at 3:01 PM Subject: Some happening when using BIND mount with network namespace. To: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, David S. Miller <davem@xxxxxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, Guillaume Nault <gnault@xxxxxxxxxx>, Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx>, Eric Dumazet <edumazet@xxxxxxxxxx>, David Howells <dhowells@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Li RongQing <lirongqing@xxxxxxxxx>, Johannes Berg <johannes.berg@xxxxxxxxx>, <linux-fsdevel@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxxxxxx> 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.
Attachment:
fix_netns_dangling_inode2.patch
Description: Binary data