Red Hat Bugzilla – Bug 448261
wireless-pending patch does not consider NULL pointer in rtl8180_max2820.c
Last modified: 2008-07-09 15:14:10 EDT
Description of problem: Following code copy from linux-2.6-wireless-pending.patch in kernel-2.6.25.3-18.fc9.src.rpm ------------------ struct rtl8180_priv *priv = dev->priv; - unsigned int chan_idx = conf ? conf->channel - 1 : 0; - u32 txpw = priv->channels[chan_idx].val & 0xFF; + int channel = ieee80211_frequency_to_channel(conf->channel->center_freq); + unsigned int chan_idx = channel - 1; + u32 txpw = priv->channels[chan_idx].hw_value & 0xFF; u32 chan = max2820_chan[chan_idx]; ------------------ In the original code, conf pointer is considered to be NULL. And in function max2820_rf_init(), there is "max2820_rf_set_channel(dev, NULL)" code. In the patched code, conf pointer is not considered to be NULL. patch to linux-2.6-wireless-pending.patch should be something like: ------------------ - int channel = ieee80211_frequency_to_channel(conf->channel->center_freq); + int channel = conf ? ( conf->channel ? ieee80211_frequency_to_channel(conf->channel->center_freq) : 1) : 1; ------------------ Version-Release number of selected component (if applicable): How reproducible: Everytime I turn up LINKSYS WPC11 ver.4 Cardbus card in Fedora 8/9 , it dumps. Steps to Reproduce: 1. Insert wireless cardbus card LINKSYS WPC11 ver.4 (rtl8180+max2820) in slot 2. ifconfig wlanX up (wlanX is the interface of LINKSYS WPC11 ver.4) 3. kernel dump trace at once Actual results: kernel dump trace. ifconfig wlanX down does not work. System can not shutdown. Expected results: wlan card works without kernel dump. Additional info: When rtl8180 card with max2820 rf up, kernel will dump: ------------------- BUG: unable to handle kernel NULL pointer dereference at 00000018 IP: [<e0a825bf>] :rtl8180:max2820_rf_set_channel+0xb/0x7b *pde = 1ac0f067 *pte = 00000000 Oops: 0000 [#1] SMP Modules linked in: arc4 ecb crypto_blkcipher rtl8180 mac80211 eeprom_93cx6 cfg80211 ipv6 ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables dm_mirror dm_mod ppdev snd_intel8x0 snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep dcdbas parport_pc snd_seq_dummy parport floppy snd_intel8x0m pcspkr snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer joydev snd i2c_i801 soundcore snd_page_alloc i2c_core 3c59x mii battery sg video ac output button iTCO_wdt iTCO_vendor_support sr_mod cdrom ata_piix pata_acpi ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 2302, comm: ifconfig Not tainted (2.6.25.3-18.fc9.i686.debug #1) EIP: 0060:[<e0a825bf>] EFLAGS: 00010246 CPU: 0 EIP is at max2820_rf_set_channel+0xb/0x7b [rtl8180] EAX: dac282c0 EBX: dac282c0 ECX: 00000000 EDX: 00000000 ESI: dac29260 EDI: c009c200 EBP: defc8e28 ESP: defc8e1c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process ifconfig (pid: 2302, ti=defc8000 task=dac3a000 task.ti=defc8000) Stack: dac29260 dac282c0 c009c200 defc8e38 e0a82696 dac29260 dac293e0 defc8e64 e0a7ff41 dac282c0 dac29260 00000004 c009c000 dac29260 0009c000 dac28c20 dac282c0 dac30580 defc8ea8 e0b1e6fc 00000000 dac30000 dac3013c dac28c20 Call Trace: [<e0a82696>] ? max2820_rf_init+0x41/0x15f [rtl8180] [<e0a7ff41>] ? rtl8180_start+0x48f/0x716 [rtl8180] [<e0b1e6fc>] ? ieee80211_open+0x237/0x458 [mac80211] [<c05d17bc>] ? dev_open+0x46/0x7e [<c05d1342>] ? dev_change_flags+0x9a/0x14d [<c060ee7c>] ? devinet_ioctl+0x218/0x52c [<c060fcdc>] ? inet_ioctl+0x8c/0xa8 [<c05c5871>] ? sock_ioctl+0x1b8/0x1da [<c05c56b9>] ? sock_ioctl+0x0/0x1da [<c0496606>] ? vfs_ioctl+0x22/0x69 [<c0496886>] ? do_vfs_ioctl+0x239/0x24c [<c04968d9>] ? sys_ioctl+0x40/0x5b [<c0405c2e>] ? syscall_call+0x7/0xb ======================= Code: ff 00 00 00 c1 e0 08 8b 12 01 c8 83 ea 80 e8 91 16 a8 df b8 01 00 00 00 e8 94 fa 9a df 5b 5d c3 55 89 e5 57 56 53 89 c3 8b 70 44 <8b> 42 18 0f b7 40 04 e8 2b 62 00 00 ba 03 00 00 00 8b 3c 85 08 EIP: [<e0a825bf>] max2820_rf_set_channel+0xb/0x7b [rtl8180] SS:ESP 0068:defc8e1c ---[ end trace af049780c8863622 ]---
Created attachment 306841 [details] 0001-rtl8180-avoid-NULL-dereference-in-max2820_rf_set_ch.patch I think this version will be sufficient -- if the mac80211 code is passing NULLs then we want to know about it, and the void return would give us no other indication. Do you find this agreeable?
I Agree with you. Your patch is sufficient. btw. I use Firefox 2.0.0.14, I have to manual select two button below or there is an bugzilla bug error - - .