linux-kernel - Fwd: Some happening when using BIND mount with network namespace.

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>] [day] [month] [year] [list]

Message-ID: <CAM7-yPSjawc1EhG--dOEJgEQ--qBuk6THGW1Qp4oHYTtDrjhSQ@mail.gmail.com>
Date:   Mon, 30 Mar 2020 16:50:56 +0900
From:   Yun Levi <ppbuk5246@...il.com>
To:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Fwd: Some happening when using BIND mount with network namespace.

---------- Forwarded message ---------
From: Yun Levi <ppbuk5246@...il.com>
Date: Mon, Mar 30, 2020 at 3:01 PM
Subject: Some happening when using BIND mount with network namespace.
To: Alexander Viro <viro@...iv.linux.org.uk>, David S. Miller
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Guillaume
Nault <gnault@...hat.com>, Nicolas Dichtel
<nicolas.dichtel@...nd.com>, Eric Dumazet <edumazet@...gle.com>, David
Howells <dhowells@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
Li RongQing <lirongqing@...du.com>, Johannes Berg
<johannes.berg@...el.com>, <linux-fsdevel@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>

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.

Download attachment "fix_netns_dangling_inode2.patch" of type "application/octet-stream" (2442 bytes)