On Tue, May 20, 2008 at 3:57 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 2008-05-20 at 15:54 +0300, Tomas Winkler wrote:
>> On Tue, May 20, 2008 at 10:56 AM, Helmut Schaa <hschaa@xxxxxxx> wrote:
>> > Fix a possible NULL pointer dereference in ieee80211_compatible_rates
>> > introduced in the patch "mac80211: fix association with some APs". If no bss
>> > is available just use all supported rates in the association request.
>> >
>> > Signed-off-by: Helmut Schaa <hschaa@xxxxxxx>
>> > ---
>> >
>> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> > index 76ad4ed..3f7f92a 100644
>> > --- a/net/mac80211/mlme.c
>> > +++ b/net/mac80211/mlme.c
>> > @@ -721,7 +721,17 @@ static void ieee80211_send_assoc(struct net_device
>> > *dev,
>> > capab |= WLAN_CAPABILITY_PRIVACY;
>> > if (bss->wmm_ie)
>> > wmm = 1;
>> > +
>> > + /* get all rates supported by the device and the AP as
>> > + * some APs don't like getting a superset of their rates
>> > + * in the association request (e.g. D-Link DAP 1353 in
>> > + * b-only mode) */
>> > + rates_len = ieee80211_compatible_rates(bss, sband, &rates);
>> > +
>> > ieee80211_rx_bss_put(dev, bss);
>> > + } else {
>> > + rates = ~0;
>> > + rates_len = sband->n_bitrates;
>> > }
>> >
>> > mgmt = (struct ieee80211_mgmt *) skb_put(skb, 24);
>> > @@ -752,10 +762,7 @@ static void ieee80211_send_assoc(struct net_device
>> > *dev,
>> > *pos++ = ifsta->ssid_len;
>> > memcpy(pos, ifsta->ssid, ifsta->ssid_len);
>> >
>> > - /* all supported rates should be added here but some APs
>> > - * (e.g. D-Link DAP 1353 in b-only mode) don't like that
>> > - * Therefore only add rates the AP supports */
>> > - rates_len = ieee80211_compatible_rates(bss, sband, &rates);
>> > + /* add all rates which were marked to be used above */
>> > supp_rates_len = rates_len;
>> > if (supp_rates_len > 8)
>> > supp_rates_len = 8;
>> >
>> >
>>
>> I found one ieee80211_rx_bss_{get,put} imbalance in
>> ieee80211_sta_join_ibss function
>> That may cause this problem yet it doesn't look like this is the case.
>> ieee80211_sta_join_ibss
>> calls ieee80211_rx_bss_put on 'bss' that it receives as an argument
>> Keep searching.
>
> Hm. Send a patch? :)
>
Searching for the real problem ...
>> I suggest to insert at least some WARN_ON(1) for the else case.
>
> Disagree, not until somebody audits the code. We already know it can
> happen and a WARN() won't help us track it down because it provides no
> additional information (stack trace is useless)
What about printk(KERN_WARN ), The else statement actually means that
something wrong happened.
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
