From: "Shengzhuo Wei" <me@cherr.cc>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: "Shengzhuo Wei" <me@cherr.cc>, <sre@kernel.org>,
<kees@kernel.org>, <linux-kernel@vger.kernel.org>,
"Andras Domokos" <andras.domokos@nokia.com>,
"Carlos Chinea" <carlos.chinea@nokia.com>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] HSI: hsi_char: Fix use-after-free on device removal
Date: Thu, 27 Aug 2026 13:09:31 +0800 [thread overview]
Message-ID: <ao_Gi6O2VQw7RUQd@pve> (raw)
In-Reply-To: <2026082727-hacker-flaky-2578@gregkh>
On 2026-08-27 06:48, Greg KH wrote:
> You now have 2 reference counts for the same structure, which is not how
> to handle this at all :(
>
> Please either make the cdev be a pointer, or use the correct cdev api
> for handling this type of common problem.
Right, adding the kref on top of the embedded cdev was the wrong call.
Thanks for catching it.
I'd like to go with the pointer option, because of how this driver is
structured: one hsc_client_data serves 16 minor numbers through a
single cdev_add(&cl_data->cdev, hsc_dev, HSC_DEVS), and cdev_device_add()
pairs one cdev with one struct device, so switching to it would mean
inventing 16 device objects for no other purpose.
With a dynamically allocated cdev (cdev_alloc() in probe, cdev_del() in
remove), the kobject reference that chrdev_open() already takes on the
cdev would keep the containing object alive until the last file
descriptor is closed, and the final release would go through the cdev's
kobject release callback instead of a hand-written kref — no second
reference count anywhere.
Does that sound like the right direction to you? If so I'll send a v2
along those lines.
Regards,
Shengzhuo
next prev parent reply other threads:[~2026-08-27 5:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 20:43 Shengzhuo Wei
2026-08-27 4:48 ` Greg KH
2026-08-27 5:09 ` Shengzhuo Wei [this message]
2026-08-27 5:15 ` Greg KH
2026-08-27 5:40 ` Shengzhuo Wei
2026-08-27 5:43 ` Greg KH
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=ao_Gi6O2VQw7RUQd@pve \
--to=me@cherr.cc \
--cc=andras.domokos@nokia.com \
--cc=carlos.chinea@nokia.com \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sre@kernel.org \
--cc=stable@vger.kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®