[Bug 101246] [BAT][BRW] NULL pointer dereference in snd_hda_codec_generic

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=101246

--- Comment #5 from Martin Peres <martin.peres at free.fr> ---
(In reply to Libin Yang from comment #4)
> From the info, it seems the hd audio module is loaded, and nodes are
> created. But aplay -l can't find the devices. This is pretty strange. Please
> try to reload the hda modules, and try playback again. And send the dmesg.

Sorry, but this is quite irrelevant to this bug, isn't it? Misconfiguration
should never cause a NULL pointer dereference, so can we concentrate on that?

Here is the function:
static void call_hp_automute(struct hda_codec *codec,
                             struct hda_jack_callback *jack)
{
        struct hda_gen_spec *spec = codec->spec;
        if (spec->hp_automute_hook)
                spec->hp_automute_hook(codec, jack);
        else
                snd_hda_gen_hp_automute(codec, jack);
}

Given that there is a NULL pointer dereference at the offset 0xa20, it means we
are trying to read a value at the offset 0xa20 of a structure to which we have
a NULL pointer. 

In this case, there are only two de-references, one on codec and one on spec.

struct hda_codec_driver is a pretty small structure while spec is pretty
gigantic and the field hp_automute_hook is down at the bottom. To I would go
for that theory first.

Now, in what cases could codec->spec be NULL? Is this something you make sure
about or are there rare cases where this could happen?

I see the following places where this happens:
 - snd_hda_codec_cleanup_for_unbind
 - snd_hda_gen_free
 - Too many other places that do not directly assign NULL, but a parameter
(unlikely to be NULL by mistake).

So, based on this, the fact that it happened twice in 26 runs and the fact that
it happened during i915's reload test, it looks quite likely to be a
use-after-free in snd_hda_codec_cleanup_for_unbind. Especially since the call
came from a workitem and there is no such thing as reference counting in the
codec structure, as far as I can tell.

Could this be fixed? I can hide the bug for our CI by adding a NULL pointer
check, but please fix this for real by making sure that codec is valid until
all users are done with their work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170608/e990a386/attachment-0001.html>