Revert "staging:r8188eu: use lib80211 CCMP decrypt"

Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt") is causing hardfreeze whenever the driver tries to connect to my wifi network. That makes the driver unusable on my system. Reverting the commit fixes the issue and the driver works properly.

Dec 29 19:21:17 gentoo kernel: BUG: scheduling while atomic: swapper/6/0/0x00000100
Dec 29 19:21:17 gentoo kernel: Modules linked in: vfat r8188eu(C) lib80211 cfg80211 rfkill snd_hda_codec_realtek amdgpu

snd_hda_codec_generic snd_hda_codec_hdmi mfd_core chash edac_mce_amd gpu_sched snd_hda_intel ttm wmi_bmof kvm drm_kms_helper snd_hda_codec irqbypass snd_hwdep crc32c_intel snd_hda_core drm snd_pcm ghash_clmulni_intel snd_timer syscopyarea cryptd snd sysfillrect pcspkr sysimgblt k10temp fb_sys_fops soundcore wmi video xts cbc ixgb ixgbe tulip cxgb3 cxgb mdio cxgb4 vxge bonding vxlan ip6_udp_tunnel udp_tunnel macvlan vmxnet3 tg3 sky2 r8169 libphy pcnet32 mii igb dca i2c_algo_bit i2c_core e1000 bnx2 atl1c msdos fat efivarfs configfs cramfs squashfs fuse nfs lockd grace sunrpc fscache ext4 jbd2 ext2 mbcache linear raid10 raid1 raid0 dm_zero dm_verity reed_solomon dm_thin_pool dm_switch dm_snapshot dm_raid raid456 async_raid6_recov async_memcpy async_pq raid6_pq dm_mirror dm_region_hash dm_log_writes dm_log_userspace dm_log dm_integrity async_xor xor async_tx dm_flakey dm_era dm_delay dm_crypt

Dec 29 19:21:17 gentoo kernel:  dm_cache_smq dm_cache dm_persistent_data libcrc32c dm_bufio dm_bio_prison dm_mod

firewire_core crc_itu_t sl811_hcd xhci_pci xhci_hcd usb_storage mpt3sas raid_class aic94xx libsas lpfc qla2xxx megaraid_sas megaraid_mbox megaraid_mm aacraid sx8 hpsa 3w_9xxx 3w_xxxx 3w_sas mptsas scsi_transport_sas mptfc scsi_transport_fc mptspi mptscsih mptbase imm parport sym53c8xx initio arcmsr aic7xxx aic79xx scsi_transport_spi sr_mod cdrom sg sd_mod pdc_adma sata_inic162x sata_mv ata_piix ahci libahci sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_via pata_jmicron pata_marvell pata_sis pata_netcell pata_pdc202xx_old pata_atiixp pata_amd pata_ali pata_it8213 pata_pcmcia pata_serverworks pata_oldpiix pata_artop pata_it821x pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_sil680 pata_pdc2027x nvme nvme_core virtio_net net_failover failover virtio_crypto crypto_engine virtio_mmio virtio_pci virtio_balloon virtio_rng

Dec 29 19:21:17 gentoo kernel:  virtio_console virtio_blk virtio_scsi virtio_ring virtio
Dec 29 19:21:17 gentoo kernel: CPU: 6 PID: 0 Comm: swapper/6 Tainted: G        WC        4.20.0-gentoo #1
Dec 29 19:21:17 gentoo kernel: Hardware name: Gigabyte Technology Co., Ltd. A320M-S2H/A320M-S2H-CF, BIOS F23 08/08/2018
Dec 29 19:21:17 gentoo kernel: Call Trace:
Dec 29 19:21:17 gentoo kernel:  <IRQ>
Dec 29 19:21:17 gentoo kernel:  dump_stack+0x67/0x9b
Dec 29 19:21:17 gentoo kernel:  __schedule_bug+0x4c/0x70
Dec 29 19:21:17 gentoo kernel:  __schedule+0x6d7/0x840
Dec 29 19:21:17 gentoo kernel:  ? enqueue_task_fair+0xa8/0x6d0
Dec 29 19:21:17 gentoo kernel:  schedule+0x28/0x80
Dec 29 19:21:17 gentoo kernel:  schedule_timeout+0x1f9/0x440
Dec 29 19:21:17 gentoo kernel:  ? _raw_spin_unlock_irqrestore+0x21/0x30
Dec 29 19:21:17 gentoo kernel:  ? wait_for_common+0xb5/0x180
Dec 29 19:21:17 gentoo kernel:  wait_for_common+0xbe/0x180
Dec 29 19:21:17 gentoo kernel:  ? wake_up_q+0x80/0x80
Dec 29 19:21:17 gentoo kernel:  ? rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  wait_for_completion_killable+0x19/0x30
Dec 29 19:21:17 gentoo kernel:  call_usermodehelper_exec+0xeb/0x170
Dec 29 19:21:17 gentoo kernel:  __request_module+0x1a1/0x430
Dec 29 19:21:17 gentoo kernel:  ? fetch_pte.isra.1+0x5/0x180
Dec 29 19:21:17 gentoo kernel:  ? iommu_unmap_page+0x6b/0x100
Dec 29 19:21:17 gentoo kernel:  ? _raw_spin_unlock_irqrestore+0x16/0x30
Dec 29 19:21:17 gentoo kernel:  rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  recv_func_posthandle+0x346/0x960 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  rtw_recv_entry+0x48e/0x980 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  rtl8188eu_recv_tasklet+0xac/0x5b0 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  ? tasklet_action_common.isra.5+0x2e/0xb0
Dec 29 19:21:17 gentoo kernel:  ? tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel:  tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel:  __do_softirq+0x104/0x365
Dec 29 19:21:17 gentoo kernel:  irq_exit+0xd1/0xe0
Dec 29 19:21:17 gentoo kernel:  do_IRQ+0x85/0xd0
Dec 29 19:21:17 gentoo kernel:  common_interrupt+0xf/0xf
Dec 29 19:21:17 gentoo kernel:  </IRQ>
Dec 29 19:21:17 gentoo kernel: RIP: 0010:cpuidle_enter_state+0xba/0x320
Dec 29 19:21:17 gentoo kernel: Code: 1f 44 00 00 31 ff e8 75 89 b3 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 3b 02 00 00 31
ff e8 9e dd b8 ff e8 e9 ad bd ff fb 85 ed <0f> 88 19 02 00 00 4c 29 fb 48 ba cf f7 53 e3 a5 9b c4 20 48 89 d8
Dec 29 19:21:17 gentoo kernel: RSP: 0018:ffffb6fd800c3ea0 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffdd
Dec 29 19:21:17 gentoo kernel: RAX: 0000000080000000 RBX: 00000016a9699495 RCX: 000000000000001f
Dec 29 19:21:17 gentoo kernel: RDX: 00000016a9699495 RSI: 0000000000000000 RDI: ffffffffb395c087
Dec 29 19:21:17 gentoo kernel: RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000020b80
Dec 29 19:21:17 gentoo kernel: R10: ffffb6fd800c3e88 R11: 000000000000008f R12: ffffffffb4521378
Dec 29 19:21:17 gentoo kernel: R13: ffff92191187c400 R14: 0000000000000000 R15: 00000016a963fe0a
Dec 29 19:21:17 gentoo kernel:  ? cpuidle_enter_state+0xb7/0x320
Dec 29 19:21:17 gentoo kernel:  do_idle+0x1ec/0x260
Dec 29 19:21:17 gentoo kernel:  cpu_startup_entry+0x19/0x20
Dec 29 19:21:17 gentoo kernel:  start_secondary+0x19a/0x1e0
Dec 29 19:21:17 gentoo kernel:  secondary_startup_64+0xa4/0xb0
Dec 29 19:21:17 gentoo kernel: bad: scheduling from the idle thread!
Dec 29 19:21:17 gentoo kernel: CPU: 6 PID: 0 Comm: swapper/6 Tainted: G        WC        4.20.0-gentoo #1
Dec 29 19:21:17 gentoo kernel: Hardware name: Gigabyte Technology Co., Ltd. A320M-S2H/A320M-S2H-CF, BIOS F23 08/08/2018
Dec 29 19:21:17 gentoo kernel: Call Trace:
Dec 29 19:21:17 gentoo kernel:  <IRQ>
Dec 29 19:21:17 gentoo kernel:  dump_stack+0x67/0x9b
Dec 29 19:21:17 gentoo kernel:  dequeue_task_idle+0x23/0x30
Dec 29 19:21:17 gentoo kernel:  __schedule+0x386/0x840
Dec 29 19:21:17 gentoo kernel:  ? enqueue_task_fair+0xa8/0x6d0
Dec 29 19:21:17 gentoo kernel:  schedule+0x28/0x80
Dec 29 19:21:17 gentoo kernel:  schedule_timeout+0x1f9/0x440
Dec 29 19:21:17 gentoo kernel:  ? _raw_spin_unlock_irqrestore+0x21/0x30
Dec 29 19:21:17 gentoo kernel:  ? wait_for_common+0xb5/0x180
Dec 29 19:21:17 gentoo kernel:  wait_for_common+0xbe/0x180
Dec 29 19:21:17 gentoo kernel:  ? wake_up_q+0x80/0x80
Dec 29 19:21:17 gentoo kernel:  ? rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  wait_for_completion_killable+0x19/0x30
Dec 29 19:21:17 gentoo kernel:  call_usermodehelper_exec+0xeb/0x170
Dec 29 19:21:17 gentoo kernel:  __request_module+0x1a1/0x430
Dec 29 19:21:17 gentoo kernel:  ? fetch_pte.isra.1+0x5/0x180
Dec 29 19:21:17 gentoo kernel:  ? iommu_unmap_page+0x6b/0x100
Dec 29 19:21:17 gentoo kernel:  ? _raw_spin_unlock_irqrestore+0x16/0x30
Dec 29 19:21:17 gentoo kernel:  rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  recv_func_posthandle+0x346/0x960 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  rtw_recv_entry+0x48e/0x980 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  rtl8188eu_recv_tasklet+0xac/0x5b0 [r8188eu]
Dec 29 19:21:17 gentoo kernel:  ? tasklet_action_common.isra.5+0x2e/0xb0
Dec 29 19:21:17 gentoo kernel:  ? tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel:  tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel:  __do_softirq+0x104/0x365
Dec 29 19:21:17 gentoo kernel:  irq_exit+0xd1/0xe0
Dec 29 19:21:17 gentoo kernel:  do_IRQ+0x85/0xd0
Dec 29 19:21:17 gentoo kernel:  common_interrupt+0xf/0xf
Dec 29 19:21:17 gentoo kernel:  </IRQ>
Dec 29 19:21:17 gentoo kernel: RIP: 0010:cpuidle_enter_state+0xba/0x320
Dec 29 19:21:17 gentoo kernel: Code: 1f 44 00 00 31 ff e8 75 89 b3 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 3b 02 00 00 31
ff e8 9e dd b8 ff e8 e9 ad bd ff fb 85 ed <0f> 88 19 02 00 00 4c 29 fb 48 ba cf f7 53 e3 a5 9b c4 20 48 89 d8
Dec 29 19:21:17 gentoo kernel: RSP: 0018:ffffb6fd800c3ea0 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffdd
Dec 29 19:21:17 gentoo kernel: RAX: 0000000080000000 RBX: 00000016a9699495 RCX: 000000000000001f
Dec 29 19:21:17 gentoo kernel: RDX: 00000016a9699495 RSI: 0000000000000000 RDI: ffffffffb395c087
Dec 29 19:21:17 gentoo kernel: RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000020b80
Dec 29 19:21:17 gentoo kernel: R10: ffffb6fd800c3e88 R11: 000000000000008f R12: ffffffffb4521378
Dec 29 19:21:17 gentoo kernel: R13: ffff92191187c400 R14: 0000000000000000 R15: 00000016a963fe0a
Dec 29 19:21:17 gentoo kernel:  ? cpuidle_enter_state+0xb7/0x320
Dec 29 19:21:17 gentoo kernel:  do_idle+0x1ec/0x260
Dec 29 19:21:17 gentoo kernel:  cpu_startup_entry+0x19/0x20
Dec 29 19:21:17 gentoo kernel:  start_secondary+0x19a/0x1e0
Dec 29 19:21:17 gentoo kernel:  secondary_startup_64+0xa4/0xb0
Dec 29 19:21:17 gentoo kernel: lib80211_crypt: registered algorithm 'CCMP'
Dec 29 19:21:17 gentoo kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

---
 drivers/staging/rtl8188eu/Kconfig             |   1 -
 drivers/staging/rtl8188eu/core/rtw_security.c | 266 ++++++++++++++----
 2 files changed, 216 insertions(+), 51 deletions(-)

index ff7832798a77..d787a091d3c1 100644
@@ -6,7 +6,6 @@ config R8188EU
 	select WEXT_PRIV
 	select LIB80211
 	select LIB80211_CRYPT_WEP
-	select LIB80211_CRYPT_CCMP
 	---help---
 	This option adds the Realtek RTL8188EU USB device such as TP-Link TL-WN725N.
 	If built as a module, it will be called r8188eu.

2.20.1

Michael,

I have verified the freezes that you see. Although I have not been able to capture the console dump, I think we are likely seeing the same problem.

I do have a work-around in that I have not gotten any freezes when I force module lib80211_crypt_ccmp to be loaded before I load module r8188eu. This clue was used in finding what seems to be a good fix.

I do not know anything about demand loading of modules using try_then_request_module(); however, I noticed that the macro actually calls __request_module(), which has the following comment:

* Load a module using the user mode module loader. The function returns
* zero on success or a negative errno code or positive exit code from
* "modprobe" on failure. Note that a successful module load does not mean
* the module did not then unload and exit on an error of its own. Callers
* must check that the service they requested is now available not blindly
* invoke it.

I note that it says "user mode module loader". Routine rtw_aes_decrypt() is likely inside some sort of locking, which leads to the "scheduling while atomic" bug that you see. As a result, I suspect that the module is not loaded, and that leads to the NULL dereference when the module is accessed. Please try the one-line patch attached, which forces lib80211 to load when r8188eu is loaded. With this patch, I have been connected to an AES-encrypted AP for nearly 3 hours with no problems.

Larry

index f7407632e80b..052656a22821 100644
@@ -1291,7 +1291,7 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
 			struct sk_buff *skb = ((struct recv_frame *)precvframe)->pkt;
 			void *crypto_private = NULL;
 			u8 *key, *pframe = skb->data;
-			struct lib80211_crypto_ops *crypto_ops = try_then_request_module(lib80211_get_crypto_ops("CCMP"), "lib80211_crypt_ccmp");
+			struct lib80211_crypto_ops *crypto_ops = lib80211_get_crypto_ops("CCMP");
 			struct security_priv *psecuritypriv = &padapter->securitypriv;
 			char iv[8], icv[8];
 

I suggested a patch for loading modules from interruptible mode, but this patch remained unclaimed ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html ).

For some reason I thought that this patch had been removed and did not track the fate of this code ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124573.html ).

I've tested your patch and it solved the issue. No freezes and dmesg looks good.

I noticed that try_then_request_module() is also used in rtw_wep_encrypt() and rtw_wep_decrypt(). I guess that also could cause problems?

Michael

So with these changes try_then_request_module() would work properly?

I reverted that patch (there are conflicts meanwhile) and removed try_then_request_module() in rtw_aes_encrypt() and it looks good.

Perhaps the same applies for the reverted TKIP changes?

Michael

That patch was quite extensive, but had only a minimal commit message. I'm surprised that it did not get a bad review, but I can see why it was ignored.

Where did you submit that patch? It certainly was never in my mailbox.

Larry

Yes, I believe it would if anyone is still using WEP. My plan is to get rid of the try_then_request_module() there as well, and for completeness, I plan to restore usage of the lib80211 routines for TKIP as well.

Once I get a chance to test the TKIP and WEP changes, I plan to have a set of 4 patches to switch the driver to using lib80211 routines for all decryption/encryption.

Larry

I send patches to emails from get_maintainer.pl list:

ivan@alpha ~/source/kernels/staging $ git format-patch 515ce733e86ee2e1bea4dba76d2d4491013d0f73^..515ce733e86ee2e1bea4dba76d2d4491013d0f73 -o /tmp/

/tmp/0001-staging-r8188eu-Use-lib80211-to-encrypt-CCMP-tx-fram.patch

ivan@alpha ~/source/kernels/staging $ ./scripts/get_maintainer.pl /tmp/0001-staging-r8188eu-Use-lib80211-to-encrypt-CCMP-tx-fram.patch

Greg Kroah-Hartman <[email protected]> (supporter:STAGING SUBSYSTEM,commit_signer:16/16=100%,authored:1/16=6%,added_lines:345/1450=24%) Ivan Safonov <[email protected]> (commit_signer:7/16=44%,authored:6/16=38%,added_lines:337/1450=23%,removed_lines:1380/1605=86%) Michael Straube <[email protected]> (commit_signer:6/16=38%,authored:6/16=38%,added_lines:715/1450=49%,removed_lines:92/1605=6%) Santha Meena Ramamoorthy <[email protected]> (commit_signer:2/16=12%,authored:2/16=12%)
Dan Carpenter <[email protected]> (commit_signer:1/16=6%)
Hans de Goede <[email protected]> (authored:1/16=6%)
[email protected] (open list:STAGING SUBSYSTEM)
[email protected] (open list)

There is no your email.

Patch "load lib80211 crypto ops from interruptible context" ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html ) is a preparation to replace

    crypto_ops = try_then_request_module(lib80211_get_crypto_ops(*), 

"lib80211_crypt_*");
with
(struct crypto_algorithm).ops

There are four other patches to use lib80211:
use lib80211 CCMP decrypt ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-February/116533.html ) Use lib80211 to encrypt (WEP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/122642.html ) Use lib80211 to encrypt (TKIP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-July/123249.html ) Use lib80211 to encrypt (CCMP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-July/123250.html )

They all crash when try_then_request_module() called.