linux-kernel - Re: [PATCH] switchtec: cleanup cdev init

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]

Message-ID: <2cd5df88-c018-3e76-fd08-483fec374932@deltatee.com>
Date:   Sun, 19 Feb 2017 21:22:35 -0700
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Keith Busch <keith.busch@...el.com>,
        Myron Stowe <myron.stowe@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Jonathan Corbet <corbet@....net>,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Emil Velikov <emil.l.velikov@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        Wei Zhang <wzhang@...com>, linux-doc@...r.kernel.org,
        linux-pci@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-nvme@...ts.infradead.org,
        Stephen Bates <stephen.bates@...rosemi.com>,
        Kurt Schwemmer <kurt.schwemmer@...rosemi.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: Re: [PATCH] switchtec: cleanup cdev init

On 19/02/17 02:43 PM, Dan Williams wrote:
> Is this race present for all file operations? I've only seen it with
> mmap() and late faults. So if these other drivers do not support mmap
> it's not clear they can trigger the failure.

I don't see how it's related to mmap only. I think there's a number of
variations on this but the race I see happens if you try to take a
reference to the device in the open/close handlers of a char device file.

If a driver puts the last remaining reference in the release handler,
then the device structure will be freed, and on returning from the
release handler, the char_dev code will try to put the last reference to
the cdev structure which may have already been free'd. There needs to be
a way for the cdev structure to take a reference on the device structure
so it doesn't get freed and the kobj.parent trick seems to accomplish
this fairly well.

Really, in any situation where there's a cdev and a device in the same
structure, the life cycles of the two become linked but their reference
counts are not and that is the problem here.

I feel like a number of developers have made the same realization
independently so this would probably be a good thing to clean up.

See these commits for examples spanning around 5 years:

4a215aa Input: fix use-after-free introduced with dynamic minor changes
0d5b7da iio: Prevent race between IIO chardev opening and IIO device
ba0ef85 tpm: Fix initialization of the cdev

Also, seems both my brother and I have independently looked into this
exact issue:

https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg25692.html

So, I think it would be a good idea to clean it up with Dan's proposed
API cleanup. If I have some time tomorrow, I may throw together a patch
set with that patch and the changes to the instances around the kernel.

Logan