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  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]
Date:   Tue, 21 Feb 2017 11:37:53 -0700
From:   Jason Gunthorpe <>
To:     Logan Gunthorpe <>
Cc:     Dan Williams <>,
        Keith Busch <>,
        Myron Stowe <>,
        Greg Kroah-Hartman <>,
        Bjorn Helgaas <>,
        Geert Uytterhoeven <>,
        Jonathan Corbet <>,
        "David S. Miller" <>,
        Andrew Morton <>,
        Emil Velikov <>,
        Mauro Carvalho Chehab <>,
        Guenter Roeck <>,
        Jarkko Sakkinen <>,
        Linus Walleij <>,
        Ryusuke Konishi <>,
        Stefan Berger <>,
        Wei Zhang <>,,,
        Linux Kernel Mailing List <>,,
        Stephen Bates <>,
        Kurt Schwemmer <>
Subject: Re: [PATCH] switchtec: cleanup cdev init

On Sun, Feb 19, 2017 at 09:22:35PM -0700, Logan Gunthorpe wrote:

> 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.

Yes, the cdev must hold a kref on the containing struct otherwise
userspace can trigger a use after free. This cannot be fixed with an
approach inside the open/release function either as the cdev core code
itself relies on the memory to exist.

I've suggested something like this before:

So I hope this will make it in, it is a step in the right direction.

If it does, would you make another patch to go further? I think
cdev_init should take enough arguments to hold the enclosing kref, API
wise there should be no API to init a cdev without the caller
specifying the enclosing struct's kref. That is the only way we will
stamp this bug-class out.

Eg look at kernel/time/posix-clock.c, it is wrong in the same way as
well - the kref_put in posix_clock_release is not enough to make it
work, clk->cdev is referenced after posix_clock_release returns by the
cdev core so this has a use-after-free.


Powered by blists - more mailing lists