Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: xlnx: zynqmp_disp: layer may be null while releasing<br /> <br /> layer-&gt;info can be null if we have an error on the first layer in<br /> zynqmp_disp_create_layers

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: zynqmp_kms: Unplug DRM device before removal<br /> <br /> Prevent userspace accesses to the DRM device from causing<br /> use-after-frees by unplugging the device before we remove it. This<br /> causes any further userspace accesses to result in an error without<br /> further calls into this driver&amp;#39;s internals.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Prevent recovery invocation during probe and resume<br /> <br /> Refactor IPC send and receive functions to allow correct<br /> handling of operations that should not trigger a recovery process.<br /> <br /> Expose ivpu_send_receive_internal(), which is now utilized by the D0i3<br /> entry, DCT initialization, and HWS initialization functions.<br /> These functions have been modified to return error codes gracefully,<br /> rather than initiating recovery.<br /> <br /> The updated functions are invoked within ivpu_probe() and ivpu_resume(),<br /> ensuring that any errors encountered during these stages result in a proper<br /> teardown or shutdown sequence. The previous approach of triggering recovery<br /> within these functions could lead to a race condition, potentially causing<br /> undefined behavior and kernel crashes due to null pointer dereferences.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()<br /> <br /> During ath12k module removal, in ath12k_core_deinit(),<br /> ath12k_mac_destroy() un-registers ah-&gt;hw from mac80211 and frees<br /> the ah-&gt;hw as well as all the ar&amp;#39;s in it. After this<br /> ath12k_core_soc_destroy()-&gt; ath12k_dp_free()-&gt; ath12k_dp_cc_cleanup()<br /> tries to access one of the freed ar&amp;#39;s from pending skb.<br /> <br /> This is because during mac destroy, driver failed to flush few<br /> data packets, which were accessed later in ath12k_dp_cc_cleanup()<br /> and freed, but using ar from the packet led to this use-after-free.<br /> <br /> BUG: KASAN: use-after-free in ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]<br /> Write of size 4 at addr ffff888150bd3514 by task modprobe/8926<br /> CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted<br /> 6.11.0-rc2-wt-ath+ #1746<br /> Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS<br /> HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7d/0xe0<br /> print_address_description.constprop.0+0x33/0x3a0<br /> print_report+0xb5/0x260<br /> ? kasan_addr_to_slab+0x24/0x80<br /> kasan_report+0xd8/0x110<br /> ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]<br /> ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]<br /> kasan_check_range+0xf3/0x1a0<br /> __kasan_check_write+0x14/0x20<br /> ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]<br /> ath12k_dp_free+0x178/0x420 [ath12k]<br /> ath12k_core_stop+0x176/0x200 [ath12k]<br /> ath12k_core_deinit+0x13f/0x210 [ath12k]<br /> ath12k_pci_remove+0xad/0x1c0 [ath12k]<br /> pci_device_remove+0x9b/0x1b0<br /> device_remove+0xbf/0x150<br /> device_release_driver_internal+0x3c3/0x580<br /> ? __kasan_check_read+0x11/0x20<br /> driver_detach+0xc4/0x190<br /> bus_remove_driver+0x130/0x2a0<br /> driver_unregister+0x68/0x90<br /> pci_unregister_driver+0x24/0x240<br /> ? find_module_all+0x13e/0x1e0<br /> ath12k_pci_exit+0x10/0x20 [ath12k]<br /> __do_sys_delete_module+0x32c/0x580<br /> ? module_flags+0x2f0/0x2f0<br /> ? kmem_cache_free+0xf0/0x410<br /> ? __fput+0x56f/0xab0<br /> ? __fput+0x56f/0xab0<br /> ? debug_smp_processor_id+0x17/0x20<br /> __x64_sys_delete_module+0x4f/0x70<br /> x64_sys_call+0x522/0x9f0<br /> do_syscall_64+0x64/0x130<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f8182c6ac8b<br /> <br /> Commit 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery<br /> scenarios") added the change to decrement the pending packets count<br /> in case of recovery which make sense as ah-&gt;hw as well all<br /> ar&amp;#39;s in it are intact during recovery, but during core deinit there<br /> is no use in decrementing packets count or waking up the empty waitq<br /> as the module is going to be removed also ar&amp;#39;s from pending skb&amp;#39;s<br /> can&amp;#39;t be used and the packets should just be released back.<br /> <br /> To fix this, avoid accessing ar from skb-&gt;cb when driver is being<br /> unregistered.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix a memleak issue when driver is removed<br /> <br /> Running "modprobe amdgpu" the second time (followed by a modprobe -r<br /> amdgpu) causes a call trace like:<br /> <br /> [ 845.212163] Memory manager not clean during takedown.<br /> [ 845.212170] WARNING: CPU: 4 PID: 2481 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2b/0x40<br /> [ 845.212177] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amddrm_buddy(OE) amdxcp(OE) amd_sched(OE) drm_exec drm_suballoc_helper drm_display_helper i2c_algo_bit amdttm(OE) amdkcl(OE) cec rc_core sunrpc qrtr intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib kvm_amd snd_hda_core snd_ump mc snd_hwdep kvm snd_pcm snd_seq_midi snd_seq_midi_event irqbypass crct10dif_pclmul snd_rawmidi polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 snd_seq aesni_intel crypto_simd snd_seq_device cryptd snd_timer mfd_aaeon asus_nb_wmi eeepc_wmi joydev asus_wmi snd ledtrig_audio sparse_keymap ccp wmi_bmof input_leds k10temp i2c_piix4 platform_profile rapl soundcore gpio_amdpt mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid ahci xhci_pci igc crc32_pclmul libahci xhci_pci_renesas video<br /> [ 845.212284] wmi [last unloaded: amddrm_ttm_helper(OE)]<br /> [ 845.212290] CPU: 4 PID: 2481 Comm: modprobe Tainted: G W OE 6.8.0-31-generic #31-Ubuntu<br /> [ 845.212296] RIP: 0010:drm_mm_takedown+0x2b/0x40<br /> [ 845.212300] Code: 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 f8 75 09 31 c0 31 ff e9 90 2e 86 00 55 48 c7 c7 d0 f6 8e 8a 48 89 e5 e8 f5 db 45 ff 0b 5d 31 c0 31 ff e9 74 2e 86 00 66 0f 1f 84 00 00 00 00 00 90<br /> [ 845.212302] RSP: 0018:ffffb11302127ae0 EFLAGS: 00010246<br /> [ 845.212305] RAX: 0000000000000000 RBX: ffff92aa5020fc08 RCX: 0000000000000000<br /> [ 845.212307] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 845.212309] RBP: ffffb11302127ae0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 845.212310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004<br /> [ 845.212312] R13: ffff92aa50200000 R14: ffff92aa5020fb10 R15: ffff92aa5020faa0<br /> [ 845.212313] FS: 0000707dd7c7c080(0000) GS:ffff92b93de00000(0000) knlGS:0000000000000000<br /> [ 845.212316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 845.212318] CR2: 00007d48b0aee200 CR3: 0000000115a58000 CR4: 0000000000f50ef0<br /> [ 845.212320] PKRU: 55555554<br /> [ 845.212321] Call Trace:<br /> [ 845.212323] <br /> [ 845.212328] ? show_regs+0x6d/0x80<br /> [ 845.212333] ? __warn+0x89/0x160<br /> [ 845.212339] ? drm_mm_takedown+0x2b/0x40<br /> [ 845.212344] ? report_bug+0x17e/0x1b0<br /> [ 845.212350] ? handle_bug+0x51/0xa0<br /> [ 845.212355] ? exc_invalid_op+0x18/0x80<br /> [ 845.212359] ? asm_exc_invalid_op+0x1b/0x20<br /> [ 845.212366] ? drm_mm_takedown+0x2b/0x40<br /> [ 845.212371] amdgpu_gtt_mgr_fini+0xa9/0x130 [amdgpu]<br /> [ 845.212645] amdgpu_ttm_fini+0x264/0x340 [amdgpu]<br /> [ 845.212770] amdgpu_bo_fini+0x2e/0xc0 [amdgpu]<br /> [ 845.212894] gmc_v12_0_sw_fini+0x2a/0x40 [amdgpu]<br /> [ 845.213036] amdgpu_device_fini_sw+0x11a/0x590 [amdgpu]<br /> [ 845.213159] amdgpu_driver_release_kms+0x16/0x40 [amdgpu]<br /> [ 845.213302] devm_drm_dev_init_release+0x5e/0x90<br /> [ 845.213305] devm_action_release+0x12/0x30<br /> [ 845.213308] release_nodes+0x42/0xd0<br /> [ 845.213311] devres_release_all+0x97/0xe0<br /> [ 845.213314] device_unbind_cleanup+0x12/0x80<br /> [ 845.213317] device_release_driver_internal+0x230/0x270<br /> [ 845.213319] ? srso_alias_return_thunk+0x5/0xfbef5<br /> <br /> This is caused by lost memory during early init phase. First time driver<br /> is removed, memory is freed but when second time the driver is inserted,<br /> VBIOS dmub is not active, since the PSP policy is to retain the driver<br /> loaded version on subsequent warm boots. Hence, communication with VBIOS<br /> DMUB fails.<br /> <br /> Fix this by aborting further comm<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()<br /> <br /> Replace one-element array with a flexible-array member in `struct<br /> mwifiex_ie_types_wildcard_ssid_params` to fix the following warning<br /> on a MT8173 Chromebook (mt8173-elm-hana):<br /> <br /> [ 356.775250] ------------[ cut here ]------------<br /> [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv-&gt;ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)<br /> [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]<br /> <br /> The "(size 6)" above is exactly the length of the SSID of the network<br /> this device was connected to. The source of the warning looks like:<br /> <br /> ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len;<br /> [...]<br /> memcpy(wildcard_ssid_tlv-&gt;ssid,<br /> user_scan_in-&gt;ssid_list[i].ssid, ssid_len);<br /> <br /> There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this<br /> struct, but it already didn&amp;#39;t account for the size of the one-element<br /> array, so it doesn&amp;#39;t need to be changed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: adjust the position to init iso data anchor<br /> <br /> MediaTek iso data anchor init should be moved to where MediaTek<br /> claims iso data interface.<br /> If there is an unexpected BT usb disconnect during setup flow,<br /> it will cause a NULL pointer crash issue when releasing iso<br /> anchor since the anchor wasn&amp;#39;t been init yet. Adjust the position<br /> to do iso data anchor init.<br /> <br /> [ 17.137991] pc : usb_kill_anchored_urbs+0x60/0x168<br /> [ 17.137998] lr : usb_kill_anchored_urbs+0x44/0x168<br /> [ 17.137999] sp : ffffffc0890cb5f0<br /> [ 17.138000] x29: ffffffc0890cb5f0 x28: ffffff80bb6c2e80<br /> [ 17.144081] gpio gpiochip0: registered chardev handle for 1 lines<br /> [ 17.148421] x27: 0000000000000000<br /> [ 17.148422] x26: ffffffd301ff4298 x25: 0000000000000003 x24: 00000000000000f0<br /> [ 17.148424] x23: 0000000000000000 x22: 00000000ffffffff x21: 0000000000000001<br /> [ 17.148425] x20: ffffffffffffffd8 x19: ffffff80c0f25560 x18: 0000000000000000<br /> [ 17.148427] x17: ffffffd33864e408 x16: ffffffd33808f7c8 x15: 0000000000200000<br /> [ 17.232789] x14: e0cd73cf80ffffff x13: 50f2137c0a0338c9 x12: 0000000000000001<br /> [ 17.239912] x11: 0000000080150011 x10: 0000000000000002 x9 : 0000000000000001<br /> [ 17.247035] x8 : 0000000000000000 x7 : 0000000000008080 x6 : 8080000000000000<br /> [ 17.254158] x5 : ffffffd33808ebc0 x4 : fffffffe033dcf20 x3 : 0000000080150011<br /> [ 17.261281] x2 : ffffff8087a91400 x1 : 0000000000000000 x0 : ffffff80c0f25588<br /> [ 17.268404] Call trace:<br /> [ 17.270841] usb_kill_anchored_urbs+0x60/0x168<br /> [ 17.275274] btusb_mtk_release_iso_intf+0x2c/0xd8 [btusb (HASH:5afe 6)]<br /> [ 17.284226] btusb_mtk_disconnect+0x14/0x28 [btusb (HASH:5afe 6)]<br /> [ 17.292652] btusb_disconnect+0x70/0x140 [btusb (HASH:5afe 6)]<br /> [ 17.300818] usb_unbind_interface+0xc4/0x240<br /> [ 17.305079] device_release_driver_internal+0x18c/0x258<br /> [ 17.310296] device_release_driver+0x1c/0x30<br /> [ 17.314557] bus_remove_device+0x140/0x160<br /> [ 17.318643] device_del+0x1c0/0x330<br /> [ 17.322121] usb_disable_device+0x80/0x180<br /> [ 17.326207] usb_disconnect+0xec/0x300<br /> [ 17.329948] hub_quiesce+0x80/0xd0<br /> [ 17.333339] hub_disconnect+0x44/0x190<br /> [ 17.337078] usb_unbind_interface+0xc4/0x240<br /> [ 17.341337] device_release_driver_internal+0x18c/0x258<br /> [ 17.346551] device_release_driver+0x1c/0x30<br /> [ 17.350810] usb_driver_release_interface+0x70/0x88<br /> [ 17.355677] proc_ioctl+0x13c/0x228<br /> [ 17.359157] proc_ioctl_default+0x50/0x80<br /> [ 17.363155] usbdev_ioctl+0x830/0xd08<br /> [ 17.366808] __arm64_sys_ioctl+0x94/0xd0<br /> [ 17.370723] invoke_syscall+0x6c/0xf8<br /> [ 17.374377] el0_svc_common+0x84/0xe0<br /> [ 17.378030] do_el0_svc+0x20/0x30<br /> [ 17.381334] el0_svc+0x34/0x60<br /> [ 17.384382] el0t_64_sync_handler+0x88/0xf0<br /> [ 17.388554] el0t_64_sync+0x180/0x188<br /> [ 17.392208] Code: f9400677 f100a2f4 54fffea0 d503201f (b8350288)<br /> [ 17.398289] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: avoid memory leak in iocharset<br /> <br /> A memleak was found as below:<br /> <br /> unreferenced object 0xffff0000d10164d8 (size 8):<br /> comm "pool-udisksd", pid 108217, jiffies 4295408555<br /> hex dump (first 8 bytes):<br /> 75 74 66 38 00 cc cc cc utf8....<br /> backtrace (crc de430d31):<br /> [] kmemleak_alloc+0xb8/0xc8<br /> [] __kmalloc_node_track_caller_noprof+0x380/0x474<br /> [] kstrdup+0x70/0xfc<br /> [] isofs_parse_param+0x228/0x2c0 [isofs]<br /> [] vfs_parse_fs_param+0xf4/0x164<br /> [] vfs_parse_fs_string+0x8c/0xd4<br /> [] vfs_parse_monolithic_sep+0xb0/0xfc<br /> [] generic_parse_monolithic+0x30/0x3c<br /> [] parse_monolithic_mount_data+0x40/0x4c<br /> [] path_mount+0x6c4/0x9ec<br /> [] do_mount+0xac/0xc4<br /> [] __arm64_sys_mount+0x16c/0x2b0<br /> [] invoke_syscall+0x7c/0x104<br /> [] el0_svc_common.constprop.1+0xe0/0x104<br /> [] do_el0_svc+0x2c/0x38<br /> [] el0_svc+0x3c/0x1b8<br /> <br /> The opt-&gt;iocharset is freed inside the isofs_fill_super function,<br /> But there may be situations where it&amp;#39;s not possible to<br /> enter this function.<br /> <br /> For example, in the get_tree_bdev_flags function,when<br /> encountering the situation where "Can&amp;#39;t mount, would change RO state,"<br /> In such a case, isofs_fill_super will not have the opportunity<br /> to be called,which means that opt-&gt;iocharset will not have the chance<br /> to be freed,ultimately leading to a memory leak.<br /> <br /> Let&amp;#39;s move the memory freeing of opt-&gt;iocharset into<br /> isofs_free_fc function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Free skb when TX metadata options are invalid<br /> <br /> When a new skb is allocated for transmitting an xsk descriptor, i.e., for<br /> every non-multibuf descriptor or the first frag of a multibuf descriptor,<br /> but the descriptor is later found to have invalid options set for the TX<br /> metadata, the new skb is never freed. This can leak skbs until the send<br /> buffer is full which makes sending more packets impossible.<br /> <br /> Fix this by freeing the skb in the error path if we are currently dealing<br /> with the first frag, i.e., an skb allocated in this iteration of<br /> xsk_build_skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix use-after-free in device_for_each_child()<br /> <br /> Syzbot has reported the following KASAN splat:<br /> <br /> BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0<br /> Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980<br /> <br /> CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> ? device_for_each_child+0x18f/0x1a0<br /> print_report+0x13a/0x4cb<br /> ? __virt_addr_valid+0x5e/0x590<br /> ? __phys_addr+0xc6/0x150<br /> ? device_for_each_child+0x18f/0x1a0<br /> kasan_report+0xda/0x110<br /> ? device_for_each_child+0x18f/0x1a0<br /> ? __pfx_dev_memalloc_noio+0x10/0x10<br /> device_for_each_child+0x18f/0x1a0<br /> ? __pfx_device_for_each_child+0x10/0x10<br /> pm_runtime_set_memalloc_noio+0xf2/0x180<br /> netdev_unregister_kobject+0x1ed/0x270<br /> unregister_netdevice_many_notify+0x123c/0x1d80<br /> ? __mutex_trylock_common+0xde/0x250<br /> ? __pfx_unregister_netdevice_many_notify+0x10/0x10<br /> ? trace_contention_end+0xe6/0x140<br /> ? __mutex_lock+0x4e7/0x8f0<br /> ? __pfx_lock_acquire.part.0+0x10/0x10<br /> ? rcu_is_watching+0x12/0xc0<br /> ? unregister_netdev+0x12/0x30<br /> unregister_netdevice_queue+0x30d/0x3f0<br /> ? __pfx_unregister_netdevice_queue+0x10/0x10<br /> ? __pfx_down_write+0x10/0x10<br /> unregister_netdev+0x1c/0x30<br /> bnep_session+0x1fb3/0x2ab0<br /> ? __pfx_bnep_session+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __pfx_woken_wake_function+0x10/0x10<br /> ? __kthread_parkme+0x132/0x200<br /> ? __pfx_bnep_session+0x10/0x10<br /> ? kthread+0x13a/0x370<br /> ? __pfx_bnep_session+0x10/0x10<br /> kthread+0x2b7/0x370<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x48/0x80<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 4974:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> __kmalloc_noprof+0x1d1/0x440<br /> hci_alloc_dev_priv+0x1d/0x2820<br /> __vhci_create_device+0xef/0x7d0<br /> vhci_write+0x2c7/0x480<br /> vfs_write+0x6a0/0xfc0<br /> ksys_write+0x12f/0x260<br /> do_syscall_64+0xc7/0x250<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 4979:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x4f/0x70<br /> kfree+0x141/0x490<br /> hci_release_dev+0x4d9/0x600<br /> bt_host_release+0x6a/0xb0<br /> device_release+0xa4/0x240<br /> kobject_put+0x1ec/0x5a0<br /> put_device+0x1f/0x30<br /> vhci_release+0x81/0xf0<br /> __fput+0x3f6/0xb30<br /> task_work_run+0x151/0x250<br /> do_exit+0xa79/0x2c30<br /> do_group_exit+0xd5/0x2a0<br /> get_signal+0x1fcd/0x2210<br /> arch_do_signal_or_restart+0x93/0x780<br /> syscall_exit_to_user_mode+0x140/0x290<br /> do_syscall_64+0xd4/0x250<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> In &amp;#39;hci_conn_del_sysfs()&amp;#39;, &amp;#39;device_unregister()&amp;#39; may be called when<br /> an underlying (kobject) reference counter is greater than 1. This<br /> means that reparenting (happened when the device is actually freed)<br /> is delayed and, during that delay, parent controller device (hciX)<br /> may be deleted. Since the latter may create a dangling pointer to<br /> freed parent, avoid that scenario by reparenting to NULL explicitly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: 6fire: Release resources at card release<br /> <br /> The current 6fire code tries to release the resources right after the<br /> call of usb6fire_chip_abort(). But at this moment, the card object<br /> might be still in use (as we&amp;#39;re calling snd_card_free_when_closed()).<br /> <br /> For avoid potential UAFs, move the release of resources to the card&amp;#39;s<br /> private_free instead of the manual call of usb6fire_chip_destroy() at<br /> the USB disconnect callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.<br /> <br /> This patch also splits the code to the disconnect and the free phases;<br /> the former is called immediately at the USB disconnect callback while<br /> the latter is called from the card destructor.