[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABg4E-moQf62Mm+Dv62yLwQaHfKHcrH54Gud1vj6bn6D7mvKJw@mail.gmail.com>
Date: Wed, 7 May 2025 13:06:09 -0400
From: Tavian Barnes <tavianator@...ianator.com>
To: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
Cc: linux-sound@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>, Daniel Baluta <daniel.baluta@....com>,
Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>, Mark Brown <broonie@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Peter Zijlstra <peterz@...radead.org>,
sound-open-firmware@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ASoC: SOF: Intel: hda: Fix UAF when reloading module
On Wed, May 7, 2025 at 11:28 AM Péter Ujfalusi
<peter.ujfalusi@...ux.intel.com> wrote:
>
> Hi,
>
> On 07/05/2025 18:10, Tavian Barnes wrote:
> > hda_generic_machine_select() appends -idisp to the tplg filename by
> > allocating a new string with devm_kasprintf(), then stores the string
> > right back into the global variable snd_soc_acpi_intel_hda_machines.
> > When the module is unloaded, this memory is freed, resulting in a global
> > variable pointing to freed memory. Reloading the module then triggers
> > a use-after-free:
> >
> > BUG: KFENCE: use-after-free read in string+0x48/0xe0
> >
> > Use-after-free read at 0x00000000967e0109 (in kfence-#99):
> > string+0x48/0xe0
> > vsnprintf+0x329/0x6e0
> > devm_kvasprintf+0x54/0xb0
> > devm_kasprintf+0x58/0x80
> > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
> > sof_probe_work+0x7f/0x600 [snd_sof]
> > process_one_work+0x17b/0x330
> > worker_thread+0x2ce/0x3f0
> > kthread+0xcf/0x100
> > ret_from_fork+0x31/0x50
> > ret_from_fork_asm+0x1a/0x30
> >
> > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64
> >
> > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago):
> > devm_kmalloc+0x52/0x120
> > devm_kvasprintf+0x66/0xb0
> > devm_kasprintf+0x58/0x80
> > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
> > sof_probe_work+0x7f/0x600 [snd_sof]
> > process_one_work+0x17b/0x330
> > worker_thread+0x2ce/0x3f0
> > kthread+0xcf/0x100
> > ret_from_fork+0x31/0x50
> > ret_from_fork_asm+0x1a/0x30
> >
> > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago):
> > release_nodes+0x43/0xb0
> > devres_release_all+0x90/0xf0
> > device_unbind_cleanup+0xe/0x70
> > device_release_driver_internal+0x1c1/0x200
> > driver_detach+0x48/0x90
> > bus_remove_driver+0x6d/0xf0
> > pci_unregister_driver+0x42/0xb0
> > __do_sys_delete_module+0x1d1/0x310
> > do_syscall_64+0x82/0x190
> > entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >
> > Fix it by copying the machine with devm_kmemdup() before we modify it.
> >
> > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach")
> > Suggested-by: Péter Ujfalusi" <peter.ujfalusi@...ux.intel.com>
> > Signed-off-by: Tavian Barnes <tavianator@...ianator.com>
> > ---
> > v3: Copy the whole machine struct instead so we can safely modify it
> > (instead of storing the name in pdata->tplg_filename, breaking other
> > fixups). The problem with v2 was pointed out by Bard Liao, with the
> > alternative fix suggested by Péter Ujfalusi.
> >
> > sound/soc/sof/intel/hda.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
> > index b34e5fdf10f1..cbf96b342005 100644
> > --- a/sound/soc/sof/intel/hda.c
> > +++ b/sound/soc/sof/intel/hda.c
> > @@ -1049,7 +1049,13 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev,
> > if (!*mach && codec_num <= 2) {
> > bool tplg_fixup = false;
> >
> > - hda_mach = snd_soc_acpi_intel_hda_machines;
> > + /* make a copy so we can modify it below */
> > + hda_mach = devm_kmemdup(sdev->dev,
> > + snd_soc_acpi_intel_hda_machines,
> > + sizeof(*hda_mach),
> > + GFP_KERNEL);
>
> We need to copy 2x the size as the snd_soc_acpi_intel_hda_machines[] has
> two entries, the second is the sentinel (all 0).
Do we? I recognize that snd_soc_acpi_intel_hda_machines is an array,
but I don't see anywhere that hda_mach or *mach are used as an array,
at least in hda.c.
I'm no expert though, if we need the sentinel I can send a v4. Thanks
for the review!
Powered by blists - more mailing lists