Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete<br /> <br /> This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to<br /> avoid crashes like bellow:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406<br /> Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341<br /> <br /> CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xd2/0x2b0 mm/kasan/report.c:521<br /> kasan_report+0x118/0x150 mm/kasan/report.c:634<br /> mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406<br /> hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334<br /> process_one_work kernel/workqueue.c:3238 [inline]<br /> process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402<br /> kthread+0x711/0x8a0 kernel/kthread.c:464<br /> ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 5987:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> kzalloc_noprof include/linux/slab.h:1039 [inline]<br /> mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252<br /> mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279<br /> remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x219/0x270 net/socket.c:727<br /> sock_write_iter+0x258/0x330 net/socket.c:1131<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x548/0xa90 fs/read_write.c:686<br /> ksys_write+0x145/0x250 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5989:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2380 [inline]<br /> slab_free mm/slub.c:4642 [inline]<br /> kfree+0x18e/0x440 mm/slub.c:4841<br /> mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242<br /> mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366<br /> hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314<br /> __sys_bind_socket net/socket.c:1810 [inline]<br /> __sys_bind+0x2c3/0x3e0 net/socket.c:1841<br /> __do_sys_bind net/socket.c:1846 [inline]<br /> __se_sys_bind net/socket.c:1844 [inline]<br /> __x64_sys_bind+0x7a/0x90 net/socket.c:1844<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: ufs: Fix a hang in the error handler<br /> <br /> ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter<br /> function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because<br /> resuming involves submitting a SCSI command and ufshcd_queuecommand()<br /> returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this<br /> hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has<br /> been called instead of before.<br /> <br /> Backtrace:<br /> __switch_to+0x174/0x338<br /> __schedule+0x600/0x9e4<br /> schedule+0x7c/0xe8<br /> schedule_timeout+0xa4/0x1c8<br /> io_schedule_timeout+0x48/0x70<br /> wait_for_common_io+0xa8/0x160 //waiting on START_STOP<br /> wait_for_completion_io_timeout+0x10/0x20<br /> blk_execute_rq+0xe4/0x1e4<br /> scsi_execute_cmd+0x108/0x244<br /> ufshcd_set_dev_pwr_mode+0xe8/0x250<br /> __ufshcd_wl_resume+0x94/0x354<br /> ufshcd_wl_runtime_resume+0x3c/0x174<br /> scsi_runtime_resume+0x64/0xa4<br /> rpm_resume+0x15c/0xa1c<br /> __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing<br /> ufshcd_err_handler+0x1a0/0xd08<br /> process_one_work+0x174/0x808<br /> worker_thread+0x15c/0x490<br /> kthread+0xf4/0x1ec<br /> ret_from_fork+0x10/0x20<br /> <br /> [ bvanassche: rewrote patch description ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix use-after-free of sq-&gt;thread in __io_uring_show_fdinfo()<br /> <br /> syzbot reports:<br /> <br /> BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60<br /> Read of size 8 at addr ffff88810de2d2c8 by task a.out/304<br /> <br /> CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x53/0x70<br /> print_report+0xd0/0x670<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? getrusage+0x1109/0x1a60<br /> kasan_report+0xce/0x100<br /> ? getrusage+0x1109/0x1a60<br /> getrusage+0x1109/0x1a60<br /> ? __pfx_getrusage+0x10/0x10<br /> __io_uring_show_fdinfo+0x9fe/0x1790<br /> ? ksys_read+0xf7/0x1c0<br /> ? do_syscall_64+0xa4/0x260<br /> ? vsnprintf+0x591/0x1100<br /> ? __pfx___io_uring_show_fdinfo+0x10/0x10<br /> ? __pfx_vsnprintf+0x10/0x10<br /> ? mutex_trylock+0xcf/0x130<br /> ? __pfx_mutex_trylock+0x10/0x10<br /> ? __pfx_show_fd_locks+0x10/0x10<br /> ? io_uring_show_fdinfo+0x57/0x80<br /> io_uring_show_fdinfo+0x57/0x80<br /> seq_show+0x38c/0x690<br /> seq_read_iter+0x3f7/0x1180<br /> ? inode_set_ctime_current+0x160/0x4b0<br /> seq_read+0x271/0x3e0<br /> ? __pfx_seq_read+0x10/0x10<br /> ? __pfx__raw_spin_lock+0x10/0x10<br /> ? __mark_inode_dirty+0x402/0x810<br /> ? selinux_file_permission+0x368/0x500<br /> ? file_update_time+0x10f/0x160<br /> vfs_read+0x177/0xa40<br /> ? __pfx___handle_mm_fault+0x10/0x10<br /> ? __pfx_vfs_read+0x10/0x10<br /> ? mutex_lock+0x81/0xe0<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ? fdget_pos+0x24d/0x4b0<br /> ksys_read+0xf7/0x1c0<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? do_user_addr_fault+0x43b/0x9c0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0f74170fc9<br /> Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 8<br /> RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9<br /> RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004<br /> RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90<br /> R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> Allocated by task 298:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_slab_alloc+0x6e/0x70<br /> kmem_cache_alloc_node_noprof+0xe8/0x330<br /> copy_process+0x376/0x5e00<br /> create_io_thread+0xab/0xf0<br /> io_sq_offload_create+0x9ed/0xf20<br /> io_uring_setup+0x12b0/0x1cc0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 22:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x37/0x50<br /> kmem_cache_free+0xc4/0x360<br /> rcu_core+0x5ff/0x19f0<br /> handle_softirqs+0x18c/0x530<br /> run_ksoftirqd+0x20/0x30<br /> smpboot_thread_fn+0x287/0x6c0<br /> kthread+0x30d/0x630<br /> ret_from_fork+0xef/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x33/0x60<br /> kasan_record_aux_stack+0x8c/0xa0<br /> __call_rcu_common.constprop.0+0x68/0x940<br /> __schedule+0xff2/0x2930<br /> __cond_resched+0x4c/0x80<br /> mutex_lock+0x5c/0xe0<br /> io_uring_del_tctx_node+0xe1/0x2b0<br /> io_uring_clean_tctx+0xb7/0x160<br /> io_uring_cancel_generic+0x34e/0x760<br /> do_exit+0x240/0x2350<br /> do_group_exit+0xab/0x220<br /> __x64_sys_exit_group+0x39/0x40<br /> x64_sys_call+0x1243/0x1840<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The buggy address belongs to the object at ffff88810de2cb00<br /> which belongs to the cache task_struct of size 3712<br /> The buggy address is located 1992 bytes inside of<br /> freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980)<br /> <br /> which is caused by the task_struct pointed to by sq-&gt;thread being<br /> released while it is being used in the function<br /> __io_uring_show_fdinfo(). Holding ctx-&gt;uring_lock does not prevent ehre<br /> relase or exit of sq-&gt;thread.<br /> <br /> Fix this by assigning and looking up -&gt;thread under RCU, and grabbing a<br /> reference to the task_struct. This e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: ets: fix a race in ets_qdisc_change()<br /> <br /> Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer<br /> fires at the wrong time.<br /> <br /> The race is as follows:<br /> <br /> CPU 0 CPU 1<br /> [1]: lock root<br /> [2]: qdisc_tree_flush_backlog()<br /> [3]: unlock root<br /> |<br /> | [5]: lock root<br /> | [6]: rehash<br /> | [7]: qdisc_tree_reduce_backlog()<br /> |<br /> [4]: qdisc_put()<br /> <br /> This can be abused to underflow a parent&amp;#39;s qlen.<br /> <br /> Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()<br /> should fix the race, because all packets will be purged from the qdisc<br /> before releasing the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: red: fix a race in __red_change()<br /> <br /> Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer<br /> fires at the wrong time.<br /> <br /> The race is as follows:<br /> <br /> CPU 0 CPU 1<br /> [1]: lock root<br /> [2]: qdisc_tree_flush_backlog()<br /> [3]: unlock root<br /> |<br /> | [5]: lock root<br /> | [6]: rehash<br /> | [7]: qdisc_tree_reduce_backlog()<br /> |<br /> [4]: qdisc_put()<br /> <br /> This can be abused to underflow a parent&amp;#39;s qlen.<br /> <br /> Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()<br /> should fix the race, because all packets will be purged from the qdisc<br /> before releasing the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix ECVF vports unload on shutdown flow<br /> <br /> Fix shutdown flow UAF when a virtual function is created on the embedded<br /> chip (ECVF) of a BlueField device. In such case the vport acl ingress<br /> table is not properly destroyed.<br /> <br /> ECVF functionality is independent of ecpf_vport_exists capability and<br /> thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not<br /> test it when enabling/disabling ECVF vports.<br /> <br /> kernel log:<br /> [] refcount_t: underflow; use-after-free.<br /> [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28<br /> refcount_warn_saturate+0x124/0x220<br /> ----------------<br /> [] Call trace:<br /> [] refcount_warn_saturate+0x124/0x220<br /> [] tree_put_node+0x164/0x1e0 [mlx5_core]<br /> [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core]<br /> [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core]<br /> [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core]<br /> [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core]<br /> [] esw_vport_cleanup+0x64/0x90 [mlx5_core]<br /> [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core]<br /> [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core]<br /> [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core]<br /> [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core]<br /> [] mlx5_sriov_detach+0x40/0x50 [mlx5_core]<br /> [] mlx5_unload+0x40/0xc4 [mlx5_core]<br /> [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core]<br /> [] mlx5_unload_one+0x3c/0x60 [mlx5_core]<br /> [] shutdown+0x7c/0xa4 [mlx5_core]<br /> [] pci_device_shutdown+0x3c/0xa0<br /> [] device_shutdown+0x170/0x340<br /> [] __do_sys_reboot+0x1f4/0x2a0<br /> [] __arm64_sys_reboot+0x2c/0x40<br /> [] invoke_syscall+0x78/0x100<br /> [] el0_svc_common.constprop.0+0x54/0x184<br /> [] do_el0_svc+0x30/0xac<br /> [] el0_svc+0x48/0x160<br /> [] el0t_64_sync_handler+0xa4/0x12c<br /> [] el0t_64_sync+0x1a4/0x1a8<br /> [] --[ end trace 9c4601d68c70030e ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mdiobus: Fix potential out-of-bounds clause 45 read/write access<br /> <br /> When using publicly available tools like &amp;#39;mdio-tools&amp;#39; to read/write data<br /> from/to network interface and its PHY via C45 (clause 45) mdiobus,<br /> there is no verification of parameters passed to the ioctl and<br /> it accepts any mdio address.<br /> Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,<br /> but it is possible to pass higher value than that via ioctl.<br /> While read/write operation should generally fail in this case,<br /> mdiobus provides stats array, where wrong address may allow out-of-bounds<br /> read/write.<br /> <br /> Fix that by adding address verification before C45 read/write operation.<br /> While this excludes this access from any statistics, it improves security of<br /> read/write operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mdiobus: Fix potential out-of-bounds read/write access<br /> <br /> When using publicly available tools like &amp;#39;mdio-tools&amp;#39; to read/write data<br /> from/to network interface and its PHY via mdiobus, there is no verification of<br /> parameters passed to the ioctl and it accepts any mdio address.<br /> Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,<br /> but it is possible to pass higher value than that via ioctl.<br /> While read/write operation should generally fail in this case,<br /> mdiobus provides stats array, where wrong address may allow out-of-bounds<br /> read/write.<br /> <br /> Fix that by adding address verification before read/write operation.<br /> While this excludes this access from any statistics, it improves security of<br /> read/write operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix TOCTOU issue in sk_is_readable()<br /> <br /> sk-&gt;sk_prot-&gt;sock_is_readable is a valid function pointer when sk resides<br /> in a sockmap. After the last sk_psock_put() (which usually happens when<br /> socket is removed from sockmap), sk-&gt;sk_prot gets restored and<br /> sk-&gt;sk_prot-&gt;sock_is_readable becomes NULL.<br /> <br /> This makes sk_is_readable() racy, if the value of sk-&gt;sk_prot is reloaded<br /> after the initial check. Which in turn may lead to a null pointer<br /> dereference.<br /> <br /> Ensure the function pointer does not turn NULL after the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> espintcp: remove encap socket caching to avoid reference leak<br /> <br /> The current scheme for caching the encap socket can lead to reference<br /> leaks when we try to delete the netns.<br /> <br /> The reference chain is: xfrm_state -&gt; enacp_sk -&gt; netns<br /> <br /> Since the encap socket is a userspace socket, it holds a reference on<br /> the netns. If we delete the espintcp state (through flush or<br /> individual delete) before removing the netns, the reference on the<br /> socket is dropped and the netns is correctly deleted. Otherwise, the<br /> netns may not be reachable anymore (if all processes within the ns<br /> have terminated), so we cannot delete the xfrm state to drop its<br /> reference on the socket.<br /> <br /> This patch results in a small (~2% in my tests) performance<br /> regression.<br /> <br /> A GC-type mechanism could be added for the socket cache, to clear<br /> references if the state hasn&amp;#39;t been used "recently", but it&amp;#39;s a lot<br /> more complex than just not caching the socket.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Don&amp;#39;t treat wb connector as physical in create_validate_stream_for_sink<br /> <br /> Don&amp;#39;t try to operate on a drm_wb_connector as an amdgpu_dm_connector.<br /> While dereferencing aconnector-&gt;base will "work" it&amp;#39;s wrong and<br /> might lead to unknown bad things. Just... don&amp;#39;t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken<br /> <br /> A SCO connection without the proper voice_setting can cause<br /> the controller to lock up.