[alsa-devel] [BUG] NULL pointer dereference in patch_sigmatel.c

[Takashi Iwai]

At Thu, 06 Aug 2009 16:41:27 +0300,
Ozan Çağlayan wrote:
> 
> 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:
> >>     
> >>> Hi,
> >>>
> >>> 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
> (/var/pisi/alsa-driver-1.0.20_20090805-41/work/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_conexant.c:384).
> 379             jack->type = type;
> 380
> 381             err = snd_jack_new(codec->bus->card, name, type,
> &jack->jack);
> 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;
> 387     }
> 388

So, either jack or jack->jack is a wrong value, likely NULL.  Could
you add a debug print to verify that?


> and then I've checked the mainline linus-2.6 and found out the following
> commit:
> 
> commit 95c0909961bc5ff18c78b2ab0d093cddc0a8b0b5
> 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
>     book-keeping.
> 
>     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.

Yes.


Takashi