Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix data races around sk-&gt;sk_shutdown.<br /> <br /> KCSAN found a data race around sk-&gt;sk_shutdown where unix_release_sock()<br /> and unix_shutdown() update it under unix_state_lock(), OTOH unix_poll()<br /> and unix_dgram_poll() read it locklessly.<br /> <br /> We need to annotate the writes and reads with WRITE_ONCE() and READ_ONCE().<br /> <br /> BUG: KCSAN: data-race in unix_poll / unix_release_sock<br /> <br /> write to 0xffff88800d0f8aec of 1 bytes by task 264 on cpu 0:<br /> unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631<br /> unix_release+0x59/0x80 net/unix/af_unix.c:1042<br /> __sock_release+0x7d/0x170 net/socket.c:653<br /> sock_close+0x19/0x30 net/socket.c:1397<br /> __fput+0x179/0x5e0 fs/file_table.c:321<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x116/0x1a0 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]<br /> syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297<br /> do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> read to 0xffff88800d0f8aec of 1 bytes by task 222 on cpu 1:<br /> unix_poll+0xa3/0x2a0 net/unix/af_unix.c:3170<br /> sock_poll+0xcf/0x2b0 net/socket.c:1385<br /> vfs_poll include/linux/poll.h:88 [inline]<br /> ep_item_poll.isra.0+0x78/0xc0 fs/eventpoll.c:855<br /> ep_send_events fs/eventpoll.c:1694 [inline]<br /> ep_poll fs/eventpoll.c:1823 [inline]<br /> do_epoll_wait+0x6c4/0xea0 fs/eventpoll.c:2258<br /> __do_sys_epoll_wait fs/eventpoll.c:2270 [inline]<br /> __se_sys_epoll_wait fs/eventpoll.c:2265 [inline]<br /> __x64_sys_epoll_wait+0xcc/0x190 fs/eventpoll.c:2265<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> value changed: 0x00 -&gt; 0x03<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 222 Comm: dbus-broker Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs()<br /> <br /> Free the cpumask allocated by create_affinity_masks() before returning<br /> from the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: TC, Fix using eswitch mapping in nic mode<br /> <br /> Cited patch is using the eswitch object mapping pool while<br /> in nic mode where it isn&amp;#39;t initialized. This results in the<br /> trace below [0].<br /> <br /> Fix that by using either nic or eswitch object mapping pool<br /> depending if eswitch is enabled or not.<br /> <br /> [0]:<br /> [ 826.446057] ==================================================================<br /> [ 826.446729] BUG: KASAN: slab-use-after-free in mlx5_add_flow_rules+0x30/0x490 [mlx5_core]<br /> [ 826.447515] Read of size 8 at addr ffff888194485830 by task tc/6233<br /> <br /> [ 826.448243] CPU: 16 PID: 6233 Comm: tc Tainted: G W 6.3.0-rc6+ #1<br /> [ 826.448890] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 826.449785] Call Trace:<br /> [ 826.450052] <br /> [ 826.450302] dump_stack_lvl+0x33/0x50<br /> [ 826.450650] print_report+0xc2/0x610<br /> [ 826.450998] ? __virt_addr_valid+0xb1/0x130<br /> [ 826.451385] ? mlx5_add_flow_rules+0x30/0x490 [mlx5_core]<br /> [ 826.451935] kasan_report+0xae/0xe0<br /> [ 826.452276] ? mlx5_add_flow_rules+0x30/0x490 [mlx5_core]<br /> [ 826.452829] mlx5_add_flow_rules+0x30/0x490 [mlx5_core]<br /> [ 826.453368] ? __kmalloc_node+0x5a/0x120<br /> [ 826.453733] esw_add_restore_rule+0x20f/0x270 [mlx5_core]<br /> [ 826.454288] ? mlx5_eswitch_add_send_to_vport_meta_rule+0x260/0x260 [mlx5_core]<br /> [ 826.455011] ? mutex_unlock+0x80/0xd0<br /> [ 826.455361] ? __mutex_unlock_slowpath.constprop.0+0x210/0x210<br /> [ 826.455862] ? mapping_add+0x2cb/0x440 [mlx5_core]<br /> [ 826.456425] mlx5e_tc_action_miss_mapping_get+0x139/0x180 [mlx5_core]<br /> [ 826.457058] ? mlx5e_tc_update_skb_nic+0xb0/0xb0 [mlx5_core]<br /> [ 826.457636] ? __kasan_kmalloc+0x77/0x90<br /> [ 826.458000] ? __kmalloc+0x57/0x120<br /> [ 826.458336] mlx5_tc_ct_flow_offload+0x325/0xe40 [mlx5_core]<br /> [ 826.458916] ? ct_kernel_enter.constprop.0+0x48/0xa0<br /> [ 826.459360] ? mlx5_tc_ct_parse_action+0xf0/0xf0 [mlx5_core]<br /> [ 826.459933] ? mlx5e_mod_hdr_attach+0x491/0x520 [mlx5_core]<br /> [ 826.460507] ? mlx5e_mod_hdr_get+0x12/0x20 [mlx5_core]<br /> [ 826.461046] ? mlx5e_tc_attach_mod_hdr+0x154/0x170 [mlx5_core]<br /> [ 826.461635] mlx5e_configure_flower+0x969/0x2110 [mlx5_core]<br /> [ 826.462217] ? _raw_spin_lock_bh+0x85/0xe0<br /> [ 826.462597] ? __mlx5e_add_fdb_flow+0x750/0x750 [mlx5_core]<br /> [ 826.463163] ? kasan_save_stack+0x2e/0x40<br /> [ 826.463534] ? down_read+0x115/0x1b0<br /> [ 826.463878] ? down_write_killable+0x110/0x110<br /> [ 826.464288] ? tc_setup_action.part.0+0x9f/0x3b0<br /> [ 826.464701] ? mlx5e_is_uplink_rep+0x4c/0x90 [mlx5_core]<br /> [ 826.465253] ? mlx5e_tc_reoffload_flows_work+0x130/0x130 [mlx5_core]<br /> [ 826.465878] tc_setup_cb_add+0x112/0x250<br /> [ 826.466247] fl_hw_replace_filter+0x230/0x310 [cls_flower]<br /> [ 826.466724] ? fl_hw_destroy_filter+0x1a0/0x1a0 [cls_flower]<br /> [ 826.467212] fl_change+0x14e1/0x2030 [cls_flower]<br /> [ 826.467636] ? sock_def_readable+0x89/0x120<br /> [ 826.468019] ? fl_tmplt_create+0x2d0/0x2d0 [cls_flower]<br /> [ 826.468509] ? kasan_unpoison+0x23/0x50<br /> [ 826.468873] ? get_random_u16+0x180/0x180<br /> [ 826.469244] ? __radix_tree_lookup+0x2b/0x130<br /> [ 826.469640] ? fl_get+0x7b/0x140 [cls_flower]<br /> [ 826.470042] ? fl_mask_put+0x200/0x200 [cls_flower]<br /> [ 826.470478] ? __mutex_unlock_slowpath.constprop.0+0x210/0x210<br /> [ 826.470973] ? fl_tmplt_create+0x2d0/0x2d0 [cls_flower]<br /> [ 826.471427] tc_new_tfilter+0x644/0x1050<br /> [ 826.471795] ? tc_get_tfilter+0x860/0x860<br /> [ 826.472170] ? __thaw_task+0x130/0x130<br /> [ 826.472525] ? arch_stack_walk+0x98/0xf0<br /> [ 826.472892] ? cap_capable+0x9f/0xd0<br /> [ 826.473235] ? security_capable+0x47/0x60<br /> [ 826.473608] rtnetlink_rcv_msg+0x1d5/0x550<br /> [ 826.473985] ? rtnl_calcit.isra.0+0x1f0/0x1f0<br /> [ 826.474383] ? __stack_depot_save+0x35/0x4c0<br /> [ 826.474779] ? kasan_save_stack+0x2e/0x40<br /> [ 826.475149] ? kasan_save_stack+0x1e/0x40<br /> [ 826.475518] ? __kasan_record_aux_stack+0x9f/0xb0<br /> [ 826.475939] ? task_work_add+0x77/0x1c0<br /> [ 826.476305] netlink_rcv_skb+0xe0/0x210<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/msm: Add missing check and destroy for alloc_ordered_workqueue"<br /> <br /> This reverts commit 643b7d0869cc7f1f7a5ac7ca6bd25d88f54e31d0.<br /> <br /> A recent patch that tried to fix up the msm_drm_init() paths with<br /> respect to the workqueue but only ended up making things worse:<br /> <br /> First, the newly added calls to msm_drm_uninit() on early errors would<br /> trigger NULL-pointer dereferences, for example, as the kms pointer would<br /> not have been initialised. (Note that these paths were also modified by<br /> a second broken error handling patch which in effect cancelled out this<br /> part when merged.)<br /> <br /> Second, the newly added allocation sanity check would still leak the<br /> previously allocated drm device.<br /> <br /> Instead of trying to salvage what was badly broken (and clearly not<br /> tested), let&amp;#39;s revert the bad commit so that clean and backportable<br /> fixes can be added in its place.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525107/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix blktrace debugfs entries leakage<br /> <br /> Commit 99d055b4fd4b ("block: remove per-disk debugfs files in<br /> blk_unregister_queue") moves blk_trace_shutdown() from<br /> blk_release_queue() to blk_unregister_queue(), this is safe if blktrace<br /> is created through sysfs, however, there is a regression in corner<br /> case.<br /> <br /> blktrace can still be enabled after del_gendisk() through ioctl if<br /> the disk is opened before del_gendisk(), and if blktrace is not shutdown<br /> through ioctl before closing the disk, debugfs entries will be leaked.<br /> <br /> Fix this problem by shutdown blktrace in disk_release(), this is safe<br /> because blk_trace_remove() is reentrant.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()<br /> <br /> KASAN reports that there&amp;#39;s a use-after-free in<br /> hci_remove_adv_monitor(). Trawling through the disassembly, you can<br /> see that the complaint is from the access in bt_dev_dbg() under the<br /> HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because<br /> msft_remove_monitor() can end up freeing the monitor<br /> structure. Specifically:<br /> hci_remove_adv_monitor() -&gt;<br /> msft_remove_monitor() -&gt;<br /> msft_remove_monitor_sync() -&gt;<br /> msft_le_cancel_monitor_advertisement_cb() -&gt;<br /> hci_free_adv_monitor()<br /> <br /> Let&amp;#39;s fix the problem by just stashing the relevant data when it&amp;#39;s<br /> still valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix warning in trace_buffered_event_disable()<br /> <br /> Warning happened in trace_buffered_event_disable() at<br /> WARN_ON_ONCE(!trace_buffered_event_ref)<br /> <br /> Call Trace:<br /> ? __warn+0xa5/0x1b0<br /> ? trace_buffered_event_disable+0x189/0x1b0<br /> __ftrace_event_enable_disable+0x19e/0x3e0<br /> free_probe_data+0x3b/0xa0<br /> unregister_ftrace_function_probe_func+0x6b8/0x800<br /> event_enable_func+0x2f0/0x3d0<br /> ftrace_process_regex.isra.0+0x12d/0x1b0<br /> ftrace_filter_write+0xe6/0x140<br /> vfs_write+0x1c9/0x6f0<br /> [...]<br /> <br /> The cause of the warning is in __ftrace_event_enable_disable(),<br /> trace_buffered_event_enable() was called once while<br /> trace_buffered_event_disable() was called twice.<br /> Reproduction script show as below, for analysis, see the comments:<br /> ```<br /> #!/bin/bash<br /> <br /> cd /sys/kernel/tracing/<br /> <br /> # 1. Register a &amp;#39;disable_event&amp;#39; command, then:<br /> # 1) SOFT_DISABLED_BIT was set;<br /> # 2) trace_buffered_event_enable() was called first time;<br /> echo &amp;#39;cmdline_proc_show:disable_event:initcall:initcall_finish&amp;#39; &gt; \<br /> set_ftrace_filter<br /> <br /> # 2. Enable the event registered, then:<br /> # 1) SOFT_DISABLED_BIT was cleared;<br /> # 2) trace_buffered_event_disable() was called first time;<br /> echo 1 &gt; events/initcall/initcall_finish/enable<br /> <br /> # 3. Try to call into cmdline_proc_show(), then SOFT_DISABLED_BIT was<br /> # set again!!!<br /> cat /proc/cmdline<br /> <br /> # 4. Unregister the &amp;#39;disable_event&amp;#39; command, then:<br /> # 1) SOFT_DISABLED_BIT was cleared again;<br /> # 2) trace_buffered_event_disable() was called second time!!!<br /> echo &amp;#39;!cmdline_proc_show:disable_event:initcall:initcall_finish&amp;#39; &gt; \<br /> set_ftrace_filter<br /> ```<br /> <br /> To fix it, IIUC, we can change to call trace_buffered_event_enable() at<br /> fist time soft-mode enabled, and call trace_buffered_event_disable() at<br /> last time soft-mode disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: sisusbvga: Add endpoint checks<br /> <br /> The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver:<br /> <br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7<br /> RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95<br /> RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000003<br /> R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600<br /> FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline]<br /> sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379<br /> sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline]<br /> sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline]<br /> sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177<br /> sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869<br /> ...<br /> <br /> The problem was caused by the fact that the driver does not check<br /> whether the endpoints it uses are actually present and have the<br /> appropriate types. This can be fixed by adding a simple check of<br /> the endpoints.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix potential user-after-free<br /> <br /> This fixes all instances of which requires to allocate a buffer calling<br /> alloc_skb which may release the chan lock and reacquire later which<br /> makes it possible that the chan is disconnected in the meantime.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: always release netdev hooks from notifier<br /> <br /> This reverts "netfilter: nf_tables: skip netdev events generated on netns removal".<br /> <br /> The problem is that when a veth device is released, the veth release<br /> callback will also queue the peer netns device for removal.<br /> <br /> Its possible that the peer netns is also slated for removal. In this<br /> case, the device memory is already released before the pre_exit hook of<br /> the peer netns runs:<br /> <br /> BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0<br /> Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> nf_hook_entry_head+0x1b8/0x1d0<br /> __nf_unregister_net_hook+0x76/0x510<br /> nft_netdev_unregister_hooks+0xa0/0x220<br /> __nft_release_hook+0x184/0x490<br /> nf_tables_pre_exit_net+0x12f/0x1b0<br /> ..<br /> <br /> Order is:<br /> 1. First netns is released, veth_dellink() queues peer netns device<br /> for removal<br /> 2. peer netns is queued for removal<br /> 3. peer netns device is released, unreg event is triggered<br /> 4. unreg event is ignored because netns is going down<br /> 5. pre_exit hook calls nft_netdev_unregister_hooks but device memory<br /> might be free&amp;#39;d already.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/efa: Fix wrong resources deallocation order<br /> <br /> When trying to destroy QP or CQ, we first decrease the refcount and<br /> potentially free memory regions allocated for the object and then<br /> request the device to destroy the object. If the device fails, the<br /> object isn&amp;#39;t fully destroyed so the user/IB core can try to destroy the<br /> object again which will lead to underflow when trying to decrease an<br /> already zeroed refcount.<br /> <br /> Deallocate resources in reverse order of allocating them to safely free<br /> them.