From: Vitor Soares <Vitor.Soares@synopsys.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>, Jose Abreu <Jose.Abreu@synopsys.com>, "corbet@lwn.net" <corbet@lwn.net>, Joao Pinto <Joao.Pinto@synopsys.com>, "arnd@arndb.de" <arnd@arndb.de>, "wsa@the-dreams.de" <wsa@the-dreams.de>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "bbrezillon@kernel.org" <bbrezillon@kernel.org>, "broonie@kernel.org" <broonie@kernel.org> Subject: RE: [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Date: Mon, 24 Feb 2020 11:04:50 +0000 [thread overview] Message-ID: <CH2PR12MB42163351853CCC029D28164BAEEC0@CH2PR12MB4216.namprd12.prod.outlook.com> (raw) In-Reply-To: <20200221233216.3b2038f8@collabora.com> Hi Boris, From: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri, Feb 21, 2020 at 22:32:16 > On Wed, 19 Feb 2020 01:20:42 +0100 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > +static int i3cdev_detach(struct device *dev, void *dummy) > > +{ > > + struct i3cdev_data *i3cdev; > > + struct i3c_device *i3c; > > + > > + if (dev->type == &i3c_masterdev_type) > > + return 0; > > + > > + i3c = dev_to_i3cdev(dev); > > + > > + i3cdev = i3cdev_get_drvdata(i3c); > > + if (!i3cdev) > > + return 0; > > + > > + /* Prevent transfers while cdev removal */ > > + mutex_lock(&i3cdev->xfer_lock); > > + cdev_del(&i3cdev->cdev); > > When cdev_del() returns there might be opened FDs pointing to your > i3cdev [1] ... Yes, I know. I protected the driver part but I missed the file->private_data. > > > + device_destroy(i3cdev_class, MKDEV(MAJOR(i3cdev_number), i3cdev->id)); > > + mutex_unlock(&i3cdev->xfer_lock); > > + > > + ida_simple_remove(&i3cdev_ida, i3cdev->id); > > + put_i3cdev(i3cdev); > > ... and you call put_i3cdev() here which frees the i3cdev object, > leading to potential use-after-free if any of the fops (ioctl, read, > write) are called on those dangling FDs. That's exactly the kind of > nightmare I'd like to avoid. > > > + > > + pr_debug("i3cdev: device [%s] unregistered\n", dev_name(&i3c->dev)); > > + > > + return 0; > > +} > > + > > [1]https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_linux_latest_source_fs_char-5Fdev.c-23L587&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=tn0F5CeiGtvih3B93GkstU1b2CzoxKklNq4vIvshH8I&s=FwSMjJ-YZFPUB6WCQM0KnFqFSVKp5KdKHdqSiu_0ycU&e=
WARNING: multiple messages have this Message-ID (diff)
From: Vitor Soares <Vitor.Soares@synopsys.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com>, Joao Pinto <Joao.Pinto@synopsys.com>, "arnd@arndb.de" <arnd@arndb.de>, "corbet@lwn.net" <corbet@lwn.net>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "wsa@the-dreams.de" <wsa@the-dreams.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "broonie@kernel.org" <broonie@kernel.org>, "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>, "bbrezillon@kernel.org" <bbrezillon@kernel.org> Subject: RE: [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Date: Mon, 24 Feb 2020 11:04:50 +0000 [thread overview] Message-ID: <CH2PR12MB42163351853CCC029D28164BAEEC0@CH2PR12MB4216.namprd12.prod.outlook.com> (raw) In-Reply-To: <20200221233216.3b2038f8@collabora.com> Hi Boris, From: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri, Feb 21, 2020 at 22:32:16 > On Wed, 19 Feb 2020 01:20:42 +0100 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > +static int i3cdev_detach(struct device *dev, void *dummy) > > +{ > > + struct i3cdev_data *i3cdev; > > + struct i3c_device *i3c; > > + > > + if (dev->type == &i3c_masterdev_type) > > + return 0; > > + > > + i3c = dev_to_i3cdev(dev); > > + > > + i3cdev = i3cdev_get_drvdata(i3c); > > + if (!i3cdev) > > + return 0; > > + > > + /* Prevent transfers while cdev removal */ > > + mutex_lock(&i3cdev->xfer_lock); > > + cdev_del(&i3cdev->cdev); > > When cdev_del() returns there might be opened FDs pointing to your > i3cdev [1] ... Yes, I know. I protected the driver part but I missed the file->private_data. > > > + device_destroy(i3cdev_class, MKDEV(MAJOR(i3cdev_number), i3cdev->id)); > > + mutex_unlock(&i3cdev->xfer_lock); > > + > > + ida_simple_remove(&i3cdev_ida, i3cdev->id); > > + put_i3cdev(i3cdev); > > ... and you call put_i3cdev() here which frees the i3cdev object, > leading to potential use-after-free if any of the fops (ioctl, read, > write) are called on those dangling FDs. That's exactly the kind of > nightmare I'd like to avoid. > > > + > > + pr_debug("i3cdev: device [%s] unregistered\n", dev_name(&i3c->dev)); > > + > > + return 0; > > +} > > + > > [1]https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_linux_latest_source_fs_char-5Fdev.c-23L587&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=tn0F5CeiGtvih3B93GkstU1b2CzoxKklNq4vIvshH8I&s=FwSMjJ-YZFPUB6WCQM0KnFqFSVKp5KdKHdqSiu_0ycU&e= _______________________________________________ linux-i3c mailing list linux-i3c@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2020-02-24 11:05 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-19 0:20 [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 0:20 ` [PATCH v3 1/5] i3c: master: export i3c_masterdev_type Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 0:20 ` [PATCH v3 2/5] i3c: master: export i3c_bus_type symbol Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 0:20 ` [PATCH v3 3/5] i3c: master: add i3c_for_each_dev helper Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 7:35 ` Greg KH 2020-02-19 7:35 ` Greg KH 2020-02-21 11:47 ` Vitor Soares 2020-02-21 11:47 ` Vitor Soares 2020-02-21 11:52 ` Greg KH 2020-02-21 11:52 ` Greg KH 2020-02-21 12:59 ` Boris Brezillon 2020-02-21 12:59 ` Boris Brezillon 2020-02-21 16:44 ` Boris Brezillon 2020-02-21 16:44 ` Boris Brezillon 2020-02-21 16:45 ` Boris Brezillon 2020-02-21 16:45 ` Boris Brezillon 2020-02-21 17:19 ` Vitor Soares 2020-02-21 17:19 ` Vitor Soares 2020-02-22 8:38 ` Boris Brezillon 2020-02-22 8:38 ` Boris Brezillon 2020-02-19 0:20 ` [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 7:37 ` Greg KH 2020-02-19 7:37 ` Greg KH 2020-02-19 8:45 ` Vitor Soares 2020-02-19 8:45 ` Vitor Soares 2020-02-19 7:39 ` Greg KH 2020-02-19 7:39 ` Greg KH 2020-02-21 11:50 ` Vitor Soares 2020-02-21 11:50 ` Vitor Soares 2020-02-19 8:42 ` Greg KH 2020-02-19 8:42 ` Greg KH 2020-02-21 22:32 ` Boris Brezillon 2020-02-21 22:32 ` Boris Brezillon 2020-02-24 11:04 ` Vitor Soares [this message] 2020-02-24 11:04 ` Vitor Soares 2020-02-24 11:22 ` Boris Brezillon 2020-02-24 11:22 ` Boris Brezillon 2020-02-19 0:20 ` [PATCH v3 5/5] add i3cdev documentation Vitor Soares 2020-02-19 0:20 ` Vitor Soares 2020-02-19 0:46 ` Vitor Soares 2020-02-19 0:46 ` Vitor Soares 2020-02-19 4:34 ` Randy Dunlap 2020-02-19 4:34 ` Randy Dunlap 2020-02-21 10:31 ` Vitor Soares 2020-02-21 10:31 ` Vitor Soares 2020-02-21 15:36 ` Randy Dunlap 2020-02-21 15:36 ` Randy Dunlap 2020-02-19 0:39 ` [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares 2020-02-19 0:39 ` Vitor Soares 2020-02-19 8:16 ` Boris Brezillon 2020-02-19 8:16 ` Boris Brezillon 2020-02-21 17:08 ` Vitor Soares 2020-02-21 17:08 ` Vitor Soares 2020-02-21 17:41 ` Boris Brezillon 2020-02-21 17:41 ` Boris Brezillon 2020-02-24 10:53 ` Vitor Soares 2020-02-24 10:53 ` Vitor Soares 2020-02-24 11:24 ` Boris Brezillon 2020-02-24 11:24 ` Boris Brezillon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CH2PR12MB42163351853CCC029D28164BAEEC0@CH2PR12MB4216.namprd12.prod.outlook.com \ --to=vitor.soares@synopsys.com \ --cc=Joao.Pinto@synopsys.com \ --cc=Jose.Abreu@synopsys.com \ --cc=arnd@arndb.de \ --cc=bbrezillon@kernel.org \ --cc=boris.brezillon@collabora.com \ --cc=broonie@kernel.org \ --cc=corbet@lwn.net \ --cc=gregkh@linuxfoundation.org \ --cc=linux-i3c@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.