Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix possible deadlocks<br /> <br /> This fixes possible deadlocks like the following caused by<br /> hci_cmd_sync_dequeue causing the destroy function to run:<br /> <br /> INFO: task kworker/u19:0:143 blocked for more than 120 seconds.<br /> Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000<br /> Workqueue: hci0 hci_cmd_sync_work [bluetooth]<br /> Call Trace:<br /> <br /> __schedule+0x374/0xaf0<br /> schedule+0x3c/0xf0<br /> schedule_preempt_disabled+0x1c/0x30<br /> __mutex_lock.constprop.0+0x3ef/0x7a0<br /> __mutex_lock_slowpath+0x13/0x20<br /> mutex_lock+0x3c/0x50<br /> mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]<br /> ? kfree+0x211/0x2a0<br /> hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]<br /> ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]<br /> cmd_complete_rsp+0x26/0x80 [bluetooth]<br /> mgmt_pending_foreach+0x4d/0x70 [bluetooth]<br /> __mgmt_power_off+0x8d/0x180 [bluetooth]<br /> ? _raw_spin_unlock_irq+0x23/0x40<br /> hci_dev_close_sync+0x445/0x5b0 [bluetooth]<br /> hci_set_powered_sync+0x149/0x250 [bluetooth]<br /> set_powered_sync+0x24/0x60 [bluetooth]<br /> hci_cmd_sync_work+0x90/0x150 [bluetooth]<br /> process_one_work+0x13e/0x300<br /> worker_thread+0x2f7/0x420<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x107/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x3d/0x60<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync<br /> <br /> This fixes the following crash:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353<br /> Read of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54<br /> <br /> CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> q kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353<br /> hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328<br /> process_one_work kernel/workqueue.c:3231 [inline]<br /> process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312<br /> worker_thread+0x86d/0xd10 kernel/workqueue.c:3389<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 5247:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:370 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387<br /> kasan_kmalloc include/linux/kasan.h:211 [inline]<br /> __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193<br /> kmalloc_noprof include/linux/slab.h:681 [inline]<br /> kzalloc_noprof include/linux/slab.h:807 [inline]<br /> mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269<br /> mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296<br /> set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394<br /> hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712<br /> hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> sock_write_iter+0x2dd/0x400 net/socket.c:1160<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xa72/0xc90 fs/read_write.c:590<br /> ksys_write+0x1a0/0x2c0 fs/read_write.c:643<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5246:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object+0xe0/0x150 mm/kasan/common.c:240<br /> __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2256 [inline]<br /> slab_free mm/slub.c:4477 [inline]<br /> kfree+0x149/0x360 mm/slub.c:4598<br /> settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443<br /> mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259<br /> __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455<br /> hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191<br /> hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]<br /> hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508<br /> sock_do_ioctl+0x158/0x460 net/socket.c:1222<br /> sock_ioctl+0x629/0x8e0 net/socket.c:1341<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()<br /> <br /> Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount<br /> (skb-&gt;users) and iucv_sock_recvmsg() does not decrement skb refcount<br /> at exit.<br /> This results in skb memory leak in skb_queue_purge() and WARN_ON in<br /> iucv_sock_destruct() during socket close. To fix this decrease<br /> skb refcount by one if MSG_PEEK is set in order to prevent memory<br /> leak and WARN_ON.<br /> <br /> WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]<br /> CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1<br /> Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)<br /> Call Trace:<br /> [] iucv_sock_destruct+0x148/0x1a0 [af_iucv]<br /> [] iucv_sock_destruct+0x80/0x1a0 [af_iucv]<br /> [] __sk_destruct+0x52/0x550<br /> [] __sock_release+0xa4/0x230<br /> [] sock_close+0x2c/0x40<br /> [] __fput+0x2e8/0x970<br /> [] task_work_run+0x1c4/0x2c0<br /> [] do_exit+0x996/0x1050<br /> [] do_group_exit+0x13a/0x360<br /> [] __s390x_sys_exit_group+0x56/0x60<br /> [] do_syscall+0x27a/0x380<br /> [] __do_syscall+0x9c/0x160<br /> [] system_call+0x70/0x98<br /> Last Breaking-Event-Address:<br /> [] iucv_sock_destruct+0x84/0x1a0 [af_iucv]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: fix potential array underflow in ucsi_ccg_sync_control()<br /> <br /> The "command" variable can be controlled by the user via debugfs. The<br /> worry is that if con_index is zero then "&amp;uc-&gt;ucsi-&gt;connector[con_index<br /> - 1]" would be an array underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix receive ring space parameters when XDP is active<br /> <br /> The MTU setting at the time an XDP multi-buffer is attached<br /> determines whether the aggregation ring will be used and the<br /> rx_skb_func handler. This is done in bnxt_set_rx_skb_mode().<br /> <br /> If the MTU is later changed, the aggregation ring setting may need<br /> to be changed and it may become out-of-sync with the settings<br /> initially done in bnxt_set_rx_skb_mode(). This may result in<br /> random memory corruption and crashes as the HW may DMA data larger<br /> than the allocated buffer size, such as:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000003c0<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1<br /> Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021<br /> RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]<br /> Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f<br /> RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202<br /> RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff<br /> RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380<br /> RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf<br /> R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980<br /> R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990<br /> FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]<br /> <br /> To address the issue, we now call bnxt_set_rx_skb_mode() within<br /> bnxt_change_mtu() to properly set the AGG rings configuration and<br /> update rx_skb_func based on the new MTU value.<br /> Additionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning of<br /> bnxt_set_rx_skb_mode() to make sure it gets set or cleared based on<br /> the current MTU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Get rid of userspace_irqchip_in_use<br /> <br /> Improper use of userspace_irqchip_in_use led to syzbot hitting the<br /> following WARN_ON() in kvm_timer_update_irq():<br /> <br /> WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459<br /> kvm_timer_update_irq+0x21c/0x394<br /> Call trace:<br /> kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459<br /> kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968<br /> kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264<br /> kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]<br /> kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]<br /> kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695<br /> kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> <br /> The following sequence led to the scenario:<br /> - Userspace creates a VM and a vCPU.<br /> - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during<br /> KVM_ARM_VCPU_INIT.<br /> - Without any other setup, such as vGIC or vPMU, userspace issues<br /> KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,<br /> kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().<br /> As a result, KVM_RUN returns after enabling the timer, but before<br /> incrementing &amp;#39;userspace_irqchip_in_use&amp;#39;:<br /> kvm_arch_vcpu_run_pid_change()<br /> ret = kvm_arm_pmu_v3_enable()<br /> if (!vcpu-&gt;arch.pmu.created)<br /> return -EINVAL;<br /> if (ret)<br /> return ret;<br /> [...]<br /> if (!irqchip_in_kernel(kvm))<br /> static_branch_inc(&amp;userspace_irqchip_in_use);<br /> - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.<br /> Since the timer is already enabled, control moves through the<br /> following flow, ultimately hitting the WARN_ON():<br /> kvm_timer_vcpu_reset()<br /> if (timer-&gt;enabled)<br /> kvm_timer_update_irq()<br /> if (!userspace_irqchip())<br /> ret = kvm_vgic_inject_irq()<br /> ret = vgic_lazy_init()<br /> if (unlikely(!vgic_initialized(kvm)))<br /> if (kvm-&gt;arch.vgic.vgic_model !=<br /> KVM_DEV_TYPE_ARM_VGIC_V2)<br /> return -EBUSY;<br /> WARN_ON(ret);<br /> <br /> Theoretically, since userspace_irqchip_in_use&amp;#39;s functionality can be<br /> simply replaced by &amp;#39;!irqchip_in_kernel()&amp;#39;, get rid of the static key<br /> to avoid the mismanagement, which also helps with the syzbot issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: imx-audmix: Add NULL check in imx_audmix_probe<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in imx_audmix_probe() is not checked.<br /> Add NULL check in imx_audmix_probe(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in hwss_setup_dpp<br /> <br /> This commit addresses a null pointer dereference issue in<br /> hwss_setup_dpp(). The issue could occur when pipe_ctx-&gt;plane_state is<br /> null. The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null<br /> before accessing. This prevents a null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe<br /> <br /> This commit addresses a null pointer dereference issue in<br /> dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:<br /> Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe")<br /> partially fixed the null pointer dereference issue. However, in<br /> dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and<br /> plane_state is accessed again through pipe_ctx. Multiple if statements<br /> directly call attributes of plane_state, leading to potential null<br /> pointer dereference issues. This patch adds necessary null checks to<br /> ensure stability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix possible resource leak in fw_log_firmware_info()<br /> <br /> The alg instance should be released under the exception path, otherwise<br /> there may be resource leak here.<br /> <br /> To mitigate this, free the alg instance with crypto_free_shash when kmalloc<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices<br /> <br /> A bogus device can provide a bNumConfigurations value that exceeds the<br /> initial value used in usb_get_configuration for allocating dev-&gt;config.<br /> <br /> This can lead to out-of-bounds accesses later, e.g. in<br /> usb_destroy_configuration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix use-after-free of slot-&gt;bus on hot remove<br /> <br /> Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.<br /> <br /> Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and<br /> commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot<br /> firmware"), USB4 v2 and v1 Host Routers are reset on probe of the<br /> thunderbolt driver.<br /> <br /> The reset clears the Presence Detect State and Data Link Layer Link Active<br /> bits at the USB4 Host Router&amp;#39;s Root Port and thus causes hot removal of the<br /> dock.<br /> <br /> The crash occurs when pciehp is unbound from one of the dock&amp;#39;s Downstream<br /> Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The<br /> pci_slot contains a pointer to the pci_bus below the Downstream Port, but<br /> a reference on that pci_bus is never acquired. The pci_bus is destroyed<br /> before the pci_slot, so a use-after-free ensues when pci_slot_release()<br /> accesses slot-&gt;bus.<br /> <br /> In principle this should not happen because pci_stop_bus_device() unbinds<br /> pciehp (and therefore destroys the pci_slot) before the pci_bus is<br /> destroyed by pci_remove_bus_device().<br /> <br /> However the stacktrace provided by Dennis shows that pciehp is unbound from<br /> pci_remove_bus_device() instead of pci_stop_bus_device(). To understand<br /> the significance of this, one needs to know that the PCI core uses a two<br /> step process to remove a portion of the hierarchy: It first unbinds all<br /> drivers in the sub-hierarchy in pci_stop_bus_device() and then actually<br /> removes the devices in pci_remove_bus_device(). There is no precaution to<br /> prevent driver binding in-between pci_stop_bus_device() and<br /> pci_remove_bus_device().<br /> <br /> In Dennis&amp;#39; case, it seems removal of the hierarchy by pciehp races with<br /> driver binding by pci_bus_add_devices(). pciehp is bound to the<br /> Downstream Port after pci_stop_bus_device() has run, so it is unbound by<br /> pci_remove_bus_device() instead of pci_stop_bus_device(). Because the<br /> pci_bus has already been destroyed at that point, accesses to it result in<br /> a use-after-free.<br /> <br /> One might conclude that driver binding needs to be prevented after<br /> pci_stop_bus_device() has run. However it seems risky that pci_slot points<br /> to pci_bus without holding a reference. Solely relying on correct ordering<br /> of driver unbind versus pci_bus destruction is certainly not defensive<br /> programming.<br /> <br /> If pci_slot has a need to access data in pci_bus, it ought to acquire a<br /> reference. Amend pci_create_slot() accordingly. Dennis reports that the<br /> crash is not reproducible with this change.<br /> <br /> Abridged stacktrace:<br /> <br /> pcieport 0000:00:07.0: PME: Signaling with IRQ 156<br /> pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+<br /> pci_bus 0000:20: dev 00, created physical slot 12<br /> pcieport 0000:00:07.0: pciehp: Slot(12): Card not present<br /> ...<br /> pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0<br /> Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1<br /> RIP: 0010:dev_driver_string+0x12/0x40<br /> pci_destroy_slot<br /> pciehp_remove<br /> pcie_port_remove_service<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> device_unregister<br /> remove_iter<br /> device_for_each_child<br /> pcie_portdrv_remove<br /> pci_device_remove<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> pci_remove_bus_device (recursive invocation)<br /> pci_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist