[alsa-devel] [BUG] NULL pointer dereference in patch_sigmatel.c
ozan at pardus.org.tr
Thu Aug 6 15:41:27 CEST 2009
Takashi Iwai wrote On 17-07-2009 12:45:
> At Fri, 17 Jul 2009 11:33:08 +0200,
> I wrote:
>> At Thu, 16 Jul 2009 22:51:50 +0300,
>> Ozan Çağlayan wrote:
>>> One of our users is having a NULL ptr dereference upon loading the
>>> snd_hda_intel module with 20090624's snapshot. There's only one commit
>>> after that date in patch_sigmatel.c so I didn't tell him to try with the
>>> latest snapshot but if you think that the bug may be related to another
>>> part of the ALSA codebase, I can make him try the latest snapshot.
>> I suppose you are using unstable tree, right?
> Looking through the stack trace, it's not...
Okay I've founded the problem. Here's the relevant code portion that
I've got from gdb:
(gdb) list *cxt5051_init+0x90
0xdf4 is in cxt5051_init
379 jack->type = type;
381 err = snd_jack_new(codec->bus->card, name, type,
382 if (err < 0)
383 return err;
384 jack->jack->private_data = jack;
385 jack->jack->private_free = conexant_free_jack_priv;
386 return 0;
and then I've checked the mainline linus-2.6 and found out the following
Author: Takashi Iwai <tiwai at suse.de>
Date: Tue Apr 14 16:15:29 2009 +0200
ALSA: hda - Avoid call of snd_jack_report at release
Don't call snd_jack_report at release of sigmatel and conexnat codecs
which results in Oops at unloading the module.
The Oops is triggered by the power-up sequence during the free due to
the pincfg restoration. Since the power-up sequence is involved with
the unsol handling, the jack reporting may be issued during that.
The Oops occurs with this jack reporting because the jack instances
have been already released but the codec doesn't do the proper
This patch adds the book-keeping of jack instances to avoid the access
to bogus pointers.
Reverting this fixed the problem on the machine which has the conexant
cx codec. Seen that the commit patches also the sigmatel one, it
explains the other oops in the beginning of this thread.
I'm not currently able to test the two machines on a newer kernel than
18.104.22.168 so I don't know if the problem is in the code or in the
wrappers/ABI-API patches in alsa-driver, etc.
More information about the Alsa-devel