netdev - Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Mar 2014 02:15:25 +0530
From:	Krishna Chaitanya <chaitanya.mgit@...il.com>
To:	Martin Pitt <martin.pitt@...ntu.com>
Cc:	Fengguang Wu <fengguang.wu@...el.com>,
	Johannes Berg <johannes.berg@...el.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

On Wed, Mar 12, 2014 at 11:04 PM, Martin Pitt <martin.pitt@...ntu.com> wrote:
>
> Fengguang Wu [2014-03-08 20:11 +0800]:
> > [    4.429993] mac80211_hwsim: ieee80211_register_hw failed (-2)
> > [...]
> > [    4.431924]  [<c12377de>] get_device+0xf/0x17
> > [    4.431924]  [<c123a165>] driver_detach+0x38/0x8f
> > [    4.431924]  [<c1239433>] bus_remove_driver+0x53/0x66
> > [    4.431924]  [<c123a535>] driver_unregister+0x38/0x3d
> > [    4.431924]  [<c123b3aa>] platform_driver_unregister+0xb/0xd
> > [    4.431924]  [<c1c4ac9f>] init_mac80211_hwsim+0x3a5/0x3b6
>
>
> So that first message is from
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/mac80211_hwsim.c?id=9ea927748#n2428
>
> At this point we registered the platform driver and the class, and it
> should have created two devices (at least for the default radios=2).
> What's odd is that I don't see this printk in your kernel log:
>
>   mac80211_hwsim: Initializing radio %d
>
> If for some reasons "radio" is 0, it would not show this and not
> initialize data->dev, but then you shouldn't get to
> ieee80211_register_hw() either as it's in the same loop. So that's a
> bit of a mystery to me.
>
> On failure, above ieee80211_register_hw() jumps to the cleanup:
>
> | failed_hw:
> |       device_unregister(data->dev);
> | failed_drvdata:
> |       ieee80211_free_hw(hw);
> | failed:
> |       mac80211_hwsim_free();
> | failed_unregister_driver:
> |       driver_unregister(&mac80211_hwsim_driver);
> |       return err;
> | }
>
>
> The mac80211_hwsim_free() function again calls
> device_unregister(data->dev) for a list (not sure which, I'm not
> certain how to interpret
>
>   list_for_each_entry_safe(data, tmpdata, &tmplist, list)
>
> ) Could that be the double free causing the memory corruption?
>
> If you are in a position to do quick builds and tests, does the crash
> go away with this?
>
>                 printk(KERN_DEBUG "mac80211_hwsim: device_bind_driver failed (%d)\n",
>                        err);
> -               goto failed_hw;
> +               goto failed_drvdata;
>         }
>
> (I'm not claiming that this is correct, just taking a stab at
> understanding what happens) If not, does it go away with changing the
> goto to failed_unregister_driver()?
>
>From the logs it looks like "rate_control_alloc" is failed,
causing ieee80211_register_hw to fail triggering the crash.
what RC are u using? Default should be minstrel, i dont see
a reason for rc alloc to fail (remote reason kmalloc failure),
so did you disable RC completely? No prints either w.r.t RC either in
dmesg?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html