linux-kernel - Re: [PATCH v2 1/2] ALSA: hda: Fix widget

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <s5hlfxh6e4p.wl-tiwai@suse.de>
Date:   Mon, 01 Jul 2019 16:08:54 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Evan Green" <evgreen@...omium.org>
Cc:     <alsa-devel@...a-project.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Amadeusz S*awi*ski" <amadeuszx.slawinski@...ux.intel.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Jaroslav Kysela" <perex@...ex.cz>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] ALSA: hda: Fix widget_mutex incomplete protection

On Wed, 26 Jun 2019 23:22:19 +0200,
Evan Green wrote:
> 
> The widget_mutex was introduced to serialize callers to
> hda_widget_sysfs_{re}init. However, its protection of the sysfs widget array
> is incomplete. For example, it is acquired around the call to
> hda_widget_sysfs_reinit(), which actually creates the new array, but isn't
> still acquired when codec->num_nodes and codec->start_nid is updated. So
> the lock ensures one thread sets up the new array at a time, but doesn't
> ensure which thread's value will end up in codec->num_nodes. If a larger
> num_nodes wins but a smaller array was set up, the next call to
> refresh_widgets() will touch free memory as it iterates over codec->num_nodes
> that aren't there.
> 
> The widget_lock really protects both the tree as well as codec->num_nodes,
> start_nid, and end_nid, so make sure it's held across that update. It should
> also be held during snd_hdac_get_sub_nodes(), so that a very old read from that
> function doesn't end up clobbering a later update.

OK, right, this fix is needed no matter whether to take my other
change to skip hda_widget_sysfs_init() call in
hda_widget_sysfs_reinit().

However...

> While in there, move the exit mutex call inside the function. This moves the
> mutex closer to the data structure it protects and removes a requirement of
> acquiring the somewhat internal widget_lock before calling sysfs_exit.

... this doesn't look better from consistency POV.  The whole code in
hdac_sysfs.c doesn't take any lock in itself.  The protection is
supposed to be done in the caller side.  So, let's keep as is now.

Also...

>  	codec->num_nodes = nums;
>  	codec->start_nid = start_nid;
>  	codec->end_nid = start_nid + nums;
> +	mutex_unlock(&codec->widget_lock);
>  	return 0;
> +
> +unlock:
> +	mutex_unlock(&codec->widget_lock);
> +	return err;

There is no need of two mutex_unlock() here.  They can be unified,

  	codec->num_nodes = nums;
  	codec->start_nid = start_nid;
  	codec->end_nid = start_nid + nums;
  unlock:
	mutex_unlock(&codec->widget_lock);
  	return err;

Could you refresh this and resubmit?


thanks,

Takashi