Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()<br /> <br /> There&amp;#39;s issue as follows:<br /> RPC: Registered rdma transport module.<br /> RPC: Registered rdma backchannel transport module.<br /> RPC: Unregistered rdma transport module.<br /> RPC: Unregistered rdma backchannel transport module.<br /> BUG: unable to handle page fault for address: fffffbfff80c609a<br /> PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0<br /> Call Trace:<br /> <br /> __die+0x1f/0x70<br /> page_fault_oops+0x2cd/0x860<br /> spurious_kernel_fault+0x36/0x450<br /> do_kern_addr_fault+0xca/0x100<br /> exc_page_fault+0x128/0x150<br /> asm_exc_page_fault+0x26/0x30<br /> percpu_counter_destroy_many+0xf7/0x2a0<br /> mmdrop+0x209/0x350<br /> finish_task_switch.isra.0+0x481/0x840<br /> schedule_tail+0xe/0xd0<br /> ret_from_fork+0x23/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not<br /> destroy the percpu counters which init in svc_rdma_proc_init().<br /> If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the<br /> &amp;#39;percpu_counters&amp;#39; list. The above issue may occur once the module is<br /> removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory<br /> leakage occurs.<br /> To solve above issue just destroy all percpu counters when<br /> register_sysctl() return NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Prevent NULL dereference in nfsd4_process_cb_update()<br /> <br /> @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no<br /> available backchannel session, setup_callback_client() will try to<br /> dereference @ses and segfault.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe<br /> <br /> In rtk_usb3phy_probe() devm_kzalloc() may return NULL<br /> but this returned value is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe<br /> <br /> In rtk_usb2phy_probe() devm_kzalloc() may return NULL<br /> but this returned value is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix use-after-free of nreq in reqsk_timer_handler().<br /> <br /> The cited commit replaced inet_csk_reqsk_queue_drop_and_put() with<br /> __inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler().<br /> <br /> Then, oreq should be passed to reqsk_put() instead of req; otherwise<br /> use-after-free of nreq could happen when reqsk is migrated but the<br /> retry attempt failed (e.g. due to timeout).<br /> <br /> Let&amp;#39;s pass oreq to reqsk_put().

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.