From: Takashi Iwai <tiwai@suse.de>
To: Curtis Malainey <cujomalainey@google.com>
Cc: alsa-devel@alsa-project.org,
Curtis Malainey <cujomalainey@chromium.org>,
Stephen Boyd <swboyd@google.com>
Subject: Re: [PATCH RFC 0/6] ALSA: Fix UAF with delayed kobj release
Date: Wed, 09 Aug 2023 15:27:30 +0200 [thread overview]
Message-ID: <87sf8se471.wl-tiwai@suse.de> (raw)
In-Reply-To: <87o7jgfxgj.wl-tiwai@suse.de>
On Wed, 09 Aug 2023 10:10:04 +0200,
Takashi Iwai wrote:
>
> On Tue, 08 Aug 2023 21:26:55 +0200,
> Curtis Malainey wrote:
> >
> > On Mon, Aug 7, 2023 at 3:34 PM Curtis Malainey <cujomalainey@google.com> wrote:
> > >
> > > > It's just a RFC and only lightly tested.
> > >
> > > Thanks for the series
> > >
> > > I will be hammering this in my test setup for next several hours
> >
> > Testing has yielded 0 bugs overnight.
> >
> > After discussion it seems like this might be more of a workaround for
> > the APIs than properly using them. Adding Stephen for more input but
> > having two kobj in the same allocation is technically not correct as
> > you essentially refcounting the same thing twice. Also having an empty
> > release function essentially nullifies the purpose of the refcounts.
> > We should probably consider something that uses the API as intended
> > rather than trying to fight their function.
>
> Moving each PCM device and control device to own object and properly
> release in the own device release could be another way to go.
>
> OTOH, I'm still wondering whether how to assure synchronization if all
> device releases are done asynchronously. If there are some
> dependencies between the resources (e.g. taking the parent's lock) at
> release, and how can it be guaranteed to work? Or, the release calls
> must not touch anything outside its own? If so, we'll still need to
> two places to finish the stuff: quiesce and release.
And now looking back at kobj code and device code, they do refcount
parent objects. Maybe the problem is in our side -- the all devices
are created with the original real device as the parent, including the
card_dev, while there are some dependencies among children. So, if we
build up a proper tree, pci_dev -> card_dev -> ctl_dev, pcm_dev, etc,
one of the problems could be solved. It's more or less similar as
what I suggested initially (referring card_dev at pcm), while changing
the parent would make it implicitly.
Takashi
next prev parent reply other threads:[~2023-08-09 13:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 13:52 [PATCH RFC 0/6] ALSA: Fix UAF with delayed kobj release Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 1/6] ALSA: core: Introduced referenced memory allocator Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 2/6] ALSA: core: Fix potential UAF by delayed kobject release of card_dev Takashi Iwai
2023-08-07 13:52 ` [PATCH 2/6] ALSA: core: Fix race between devres and delayed kobject release for card_dev Takashi Iwai
2023-08-07 13:56 ` Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 3/6] ALSA: core: Associate memory reference with device initialization Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 4/6] ALSA: pcm: Release memory with reference Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 5/6] ALSA: control: Reference card by ctl_dev Takashi Iwai
2023-08-07 13:52 ` [PATCH RFC 6/6] ALSA: compress: Reference card by the device Takashi Iwai
2023-08-07 22:34 ` [PATCH RFC 0/6] ALSA: Fix UAF with delayed kobj release Curtis Malainey
2023-08-08 19:26 ` Curtis Malainey
2023-08-09 8:10 ` Takashi Iwai
2023-08-09 13:27 ` Takashi Iwai [this message]
2023-08-09 21:11 ` Curtis Malainey
2023-08-13 8:08 ` Takashi Iwai
2023-08-14 20:20 ` Curtis Malainey
2023-08-15 16:07 ` Takashi Iwai
2023-08-15 21:32 ` Curtis Malainey
2023-08-16 5:35 ` Takashi Iwai
2023-08-16 5:47 ` Takashi Iwai
2023-08-16 21:46 ` Curtis Malainey
2023-08-17 6:21 ` Takashi Iwai
2023-08-17 17:25 ` Curtis Malainey
2023-08-18 0:41 ` Curtis Malainey
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=87sf8se471.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=cujomalainey@chromium.org \
--cc=cujomalainey@google.com \
--cc=swboyd@google.com \
/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 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.