[PATCH] p2p: fix rogue pointer access

[Reinette Chatre]

Hi Jouni,

On Thu, 2011-10-20 at 00:34 +0300, Jouni Malinen wrote:
> On Wed, Oct 19, 2011 at 10:30:13AM -0700, Angie Chinchilla wrote:
> > From: Reinette Chatre <reinette.chatre at intel.com>
> > A problem is that the global p2p_config structure contains a pointer to the
> > newly created wpa_supplicant structure associated with the interface.
> 
> Incorrect.. The pointer in global P2P data is supposed to point to the
> parent interface, i.e., the wpa_s instance that did indeed run
> p2p_init().
> > When
> > an interface is created it thus needs to be ensured that the global P2P data
> > structures point to the right interface information. Thus, when an interface
> > is created the global P2P information needs to be updated to point to the new
> > wpa_supplicant struct.
> 
> No, that is not the way this is supposed to work. The new interface here
> is likely to be used for a P2P group and at the end of that group, it
> will be removed. That would leave wrong pointers in the global P2P data.

The symptom I see is when I request a P2P Find then there is sometimes a
crash that results from the wpa_s->off_channel_freq being something very
wrong and it is used in stop_listen which is called in p2p_find before
anything else is run. In stop_listen code is thus run that shouldn't and
that causes problems. What I have found is that this strange value is a
result of wpa_s not pointing to the current interface information, which
prompted this patch.

> > If the above is not done and a new interface is created, for example after 
> > a resume, then the P2P data will point to invalid memory and weird things
> > happen.
> 
> There is something else here.. Are you removing the parent interface
> somehow? That is not really supported currently and I guess it should
> really result in removing all dynamic P2P interfaces and deinitializing
> the global P2P data..

I do not have any changes to wpa_supplicant apart from this patch. I
request a P2P Find via D-Bus and then sometimes see this issue. What I
noticed was that when this occurs the logs contain information that,
from the time wpa_supplicant started, the interface was recreated (and
shows up with a different D-Bus id) ... I just assumed it happens after
resume from suspend.

Reinette