Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb<br /> <br /> When removing kernel modules by:<br /> rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core<br /> <br /> Driver uses skb_queue_purge() to purge TX skb, but not report tx status<br /> causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()<br /> to correct this.<br /> <br /> Since ieee80211_purge_tx_queue() doesn&amp;#39;t take locks, to prevent racing<br /> between TX work and purge TX queue, flush and destroy TX work in advance.<br /> <br /> wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local<br /> choice (Reason: 3=DEAUTH_LEAVING)<br /> ------------[ cut here ]------------<br /> Have pending ack frames!<br /> WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> CPU: 3 PID: 9232 Comm: rmmod Tainted: G C<br /> 6.10.1-200.fc40.aarch64 #1<br /> Hardware name: pine64 Pine64 PinePhone Braveheart<br /> (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> sp : ffff80008c1b37b0<br /> x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0<br /> x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff<br /> x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000<br /> x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964<br /> x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0<br /> x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000<br /> Call trace:<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> idr_for_each+0x74/0x110<br /> ieee80211_free_hw+0x44/0xe8 [mac80211]<br /> rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]<br /> sdio_bus_remove+0x44/0x180<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1d4/0x238<br /> driver_detach+0x54/0xc0<br /> bus_remove_driver+0x78/0x108<br /> driver_unregister+0x38/0x78<br /> sdio_unregister_driver+0x2c/0x40<br /> rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]<br /> __do_sys_delete_module.isra.0+0x190/0x338<br /> __arm64_sys_delete_module+0x1c/0x30<br /> invoke_syscall+0x74/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix shift-out-of-bounds in dbSplit<br /> <br /> When dmt_budmin is less than zero, it causes errors<br /> in the later stages. Added a check to return an error beforehand<br /> in dbAllocCtl itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: array-index-out-of-bounds fix in dtReadFirst<br /> <br /> The value of stbl can be sometimes out of bounds due<br /> to a bad filesystem. Added a check with appopriate return<br /> of error code in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: avoid NULL pointer error during sdio remove<br /> <br /> When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio<br /> workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON<br /> is set to yes, kernel panic will happen:<br /> Call trace:<br /> destroy_workqueue+0x1c/0x258<br /> ath10k_sdio_remove+0x84/0x94<br /> sdio_bus_remove+0x50/0x16c<br /> device_release_driver_internal+0x188/0x25c<br /> device_driver_detach+0x20/0x2c<br /> <br /> This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call<br /> ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()<br /> will finally be called in ath10k_core_destroy(). This function will free<br /> struct cfg80211_registered_device *rdev and all its members, including<br /> wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio<br /> workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.<br /> <br /> After device release, destroy_workqueue() will use NULL pointer then the<br /> kernel panic happen.<br /> <br /> Call trace:<br /> ath10k_sdio_remove<br /> -&gt;ath10k_core_unregister<br /> ……<br /> -&gt;ath10k_core_stop<br /> -&gt;ath10k_hif_stop<br /> -&gt;ath10k_sdio_irq_disable<br /> -&gt;ath10k_hif_power_down<br /> -&gt;del_timer_sync(&amp;ar_sdio-&gt;sleep_timer)<br /> -&gt;ath10k_core_destroy<br /> -&gt;ath10k_mac_destroy<br /> -&gt;ieee80211_free_hw<br /> -&gt;wiphy_free<br /> ……<br /> -&gt;wiphy_dev_release<br /> -&gt;destroy_workqueue<br /> <br /> Need to call destroy_workqueue() before ath10k_core_destroy(), free<br /> the work queue buffer first and then free pointer of work queue by<br /> ath10k_core_destroy(). This order matches the error path order in<br /> ath10k_sdio_probe().<br /> <br /> No work will be queued on sdio workqueue between it is destroyed and<br /> ath10k_core_destroy() is called. Based on the call_stack above, the<br /> reason is:<br /> Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and<br /> ath10k_sdio_irq_disable() will queue work on sdio workqueue.<br /> Sleep timer will be deleted before ath10k_core_destroy() in<br /> ath10k_hif_power_down().<br /> ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().<br /> ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif<br /> bus, so ath10k_sdio_hif_tx_sg() won&amp;#39;t be called anymore.<br /> <br /> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: inet6: do not leave a dangling sk pointer in inet6_create()<br /> <br /> sock_init_data() attaches the allocated sk pointer to the provided sock<br /> object. If inet6_create() fails later, the sk object is released, but the<br /> sock object retains the dangling sk pointer, which may cause use-after-free<br /> later.<br /> <br /> Clear the sock sk pointer on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: inet: do not leave a dangling sk pointer in inet_create()<br /> <br /> sock_init_data() attaches the allocated sk object to the provided sock<br /> object. If inet_create() fails later, the sk object is freed, but the<br /> sock object retains the dangling pointer, which may create use-after-free<br /> later.<br /> <br /> Clear the sk pointer in the sock object on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()<br /> <br /> sock_init_data() attaches the allocated sk object to the provided sock<br /> object. If ieee802154_create() fails later, the allocated sk object is<br /> freed, but the dangling pointer remains in the provided sock object, which<br /> may allow use-after-free.<br /> <br /> Clear the sk pointer in the sock object on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_can: do not leave a dangling sk pointer in can_create()<br /> <br /> On error can_create() frees the allocated sk object, but sock_init_data()<br /> has already attached it to the provided sock object. This will leave a<br /> dangling sk pointer in the sock object and may cause use-after-free later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()<br /> <br /> bt_sock_alloc() attaches allocated sk object to the provided sock object.<br /> If rfcomm_dlc_alloc() fails, we release the sk object, but leave the<br /> dangling pointer in the sock object, which may cause use-after-free.<br /> <br /> Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()<br /> <br /> bt_sock_alloc() allocates the sk object and attaches it to the provided<br /> sock object. On error l2cap_sock_alloc() frees the sk object, but the<br /> dangling pointer is still attached to the sock object, which may create<br /> use-after-free in other code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Create all dump files during debugfs initialization<br /> <br /> For the current debugfs of hisi_sas, after user triggers dump, the<br /> driver allocate memory space to save the register information and create<br /> debugfs files to display the saved information. In this process, the<br /> debugfs files created after each dump.<br /> <br /> Therefore, when the dump is triggered while the driver is unbind, the<br /> following hang occurs:<br /> <br /> [67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [67840.862947] Mem abort info:<br /> [67840.865855] ESR = 0x0000000096000004<br /> [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [67840.875125] SET = 0, FnV = 0<br /> [67840.878291] EA = 0, S1PTW = 0<br /> [67840.881545] FSC = 0x04: level 0 translation fault<br /> [67840.886528] Data abort info:<br /> [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000<br /> [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000<br /> [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [67841.003628] pc : down_write+0x30/0x98<br /> [67841.007546] lr : start_creating.part.0+0x60/0x198<br /> [67841.012495] sp : ffff8000b979ba20<br /> [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40<br /> [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8<br /> [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18<br /> [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020<br /> [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff<br /> [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18<br /> [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18<br /> [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9<br /> [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001<br /> [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0<br /> [67841.089759] Call trace:<br /> [67841.092456] down_write+0x30/0x98<br /> [67841.096017] start_creating.part.0+0x60/0x198<br /> [67841.100613] debugfs_create_dir+0x48/0x1f8<br /> [67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]<br /> [67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]<br /> [67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]<br /> [67841.125115] full_proxy_write+0x68/0xc8<br /> [67841.129175] vfs_write+0xd8/0x3f0<br /> [67841.132708] ksys_write+0x70/0x108<br /> [67841.136317] __arm64_sys_write+0x24/0x38<br /> [67841.140440] invoke_syscall+0x50/0x128<br /> [67841.144385] el0_svc_common.constprop.0+0xc8/0xf0<br /> [67841.149273] do_el0_svc+0x24/0x38<br /> [67841.152773] el0_svc+0x38/0xd8<br /> [67841.156009] el0t_64_sync_handler+0xc0/0xc8<br /> [67841.160361] el0t_64_sync+0x1a4/0x1a8<br /> [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)<br /> [67841.170443] ---[ end trace 0000000000000000 ]---<br /> <br /> To fix this issue, create all directories and files during debugfs<br /> initialization. In this way, the driver only needs to allocate memory<br /> space to save information each time the user triggers dumping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: Use disable_delayed_work_sync<br /> <br /> This makes use of disable_delayed_work_sync instead<br /> cancel_delayed_work_sync as it not only cancel the ongoing work but also<br /> disables new submit which is disarable since the object holding the work<br /> is about to be freed.