Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gvt: fix vgpu debugfs clean in remove<br /> <br /> Check carefully on root debugfs available when destroying vgpu,<br /> e.g in remove case drm minor&amp;#39;s debugfs root might already be destroyed,<br /> which led to kernel oops like below.<br /> <br /> Console: switching to colour dummy device 80x25<br /> i915 0000:00:02.0: MDEV: Unregistering<br /> intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14<br /> BUG: kernel NULL pointer dereference, address: 0000000000000150<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6<br /> Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022<br /> RIP: 0010:__lock_acquire+0x5e2/0x1f90<br /> Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0<br /> RSP: 0018:ffff9f770274f948 EFLAGS: 00010046<br /> RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000<br /> R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> lock_acquire+0xbf/0x2b0<br /> ? simple_recursive_removal+0xa5/0x2b0<br /> ? lock_release+0x13d/0x2d0<br /> down_write+0x2a/0xd0<br /> ? simple_recursive_removal+0xa5/0x2b0<br /> simple_recursive_removal+0xa5/0x2b0<br /> ? start_creating.part.0+0x110/0x110<br /> ? _raw_spin_unlock+0x29/0x40<br /> debugfs_remove+0x40/0x60<br /> intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt]<br /> intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt]<br /> intel_vgpu_release_dev+0xe/0x20 [kvmgt]<br /> device_release+0x30/0x80<br /> kobject_put+0x79/0x1b0<br /> device_release_driver_internal+0x1b8/0x230<br /> bus_remove_device+0xec/0x160<br /> device_del+0x189/0x400<br /> ? up_write+0x9c/0x1b0<br /> ? mdev_device_remove_common+0x60/0x60 [mdev]<br /> mdev_device_remove_common+0x22/0x60 [mdev]<br /> mdev_device_remove_cb+0x17/0x20 [mdev]<br /> device_for_each_child+0x56/0x80<br /> mdev_unregister_parent+0x5a/0x81 [mdev]<br /> intel_gvt_clean_device+0x2d/0xe0 [kvmgt]<br /> intel_gvt_driver_remove+0x2e/0xb0 [i915]<br /> i915_driver_remove+0xac/0x100 [i915]<br /> i915_pci_remove+0x1a/0x30 [i915]<br /> pci_device_remove+0x31/0xa0<br /> device_release_driver_internal+0x1b8/0x230<br /> unbind_store+0xd8/0x100<br /> kernfs_fop_write_iter+0x156/0x210<br /> vfs_write+0x236/0x4a0<br /> ksys_write+0x61/0xd0<br /> do_syscall_64+0x55/0x80<br /> ? find_held_lock+0x2b/0x80<br /> ? lock_release+0x13d/0x2d0<br /> ? up_read+0x17/0x20<br /> ? lock_is_held_type+0xe3/0x140<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fc9b2c9e0c4<br /> Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48<br /> RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4<br /> RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001<br /> RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d<br /> R13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00<br /> <br /> Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_fq: fix integer overflow of "credit"<br /> <br /> if sch_fq is configured with "initial quantum" having values greater than<br /> INT_MAX, the first assignment of "credit" does signed integer overflow to<br /> a very negative value.<br /> In this situation, the syzkaller script provided by Cristoph triggers the<br /> CPU soft-lockup warning even with few sockets. It&amp;#39;s not an infinite loop,<br /> but "credit" wasn&amp;#39;t probably meant to be minus 2Gb for each new flow.<br /> Capping "initial quantum" to INT_MAX proved to fix the issue.<br /> <br /> v2: validation of "initial quantum" is done in fq_policy, instead of open<br /> coding in fq_change() _ suggested by Jakub Kicinski

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()<br /> <br /> The si-&gt;lock must be held when deleting the si from the available list. <br /> Otherwise, another thread can re-add the si to the available list, which<br /> can lead to memory corruption. The only place we have found where this<br /> happens is in the swapoff path. This case can be described as below:<br /> <br /> core 0 core 1<br /> swapoff<br /> <br /> del_from_avail_list(si) waiting<br /> <br /> try lock si-&gt;lock acquire swap_avail_lock<br /> and re-add si into<br /> swap_avail_head<br /> <br /> acquire si-&gt;lock but missing si already being added again, and continuing<br /> to clear SWP_WRITEOK, etc.<br /> <br /> It can be easily found that a massive warning messages can be triggered<br /> inside get_swap_pages() by some special cases, for example, we call<br /> madvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,<br /> run much swapon-swapoff operations (e.g. stress-ng-swap).<br /> <br /> However, in the worst case, panic can be caused by the above scene. In<br /> swapoff(), the memory used by si could be kept in swap_info[] after<br /> turning off a swap. This means memory corruption will not be caused<br /> immediately until allocated and reset for a new swap in the swapon path. <br /> A panic message caused: (with CONFIG_PLIST_DEBUG enabled)<br /> <br /> ------------[ cut here ]------------<br /> top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a<br /> prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d<br /> next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a<br /> WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70<br /> Modules linked in: rfkill(E) crct10dif_ce(E)...<br /> CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+<br /> Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : plist_check_prev_next_node+0x50/0x70<br /> lr : plist_check_prev_next_node+0x50/0x70<br /> sp : ffff0018009d3c30<br /> x29: ffff0018009d3c40 x28: ffff800011b32a98<br /> x27: 0000000000000000 x26: ffff001803908000<br /> x25: ffff8000128ea088 x24: ffff800011b32a48<br /> x23: 0000000000000028 x22: ffff001800875c00<br /> x21: ffff800010f9e520 x20: ffff001800875c00<br /> x19: ffff001800fdc6e0 x18: 0000000000000030<br /> x17: 0000000000000000 x16: 0000000000000000<br /> x15: 0736076307640766 x14: 0730073007380731<br /> x13: 0736076307640766 x12: 0730073007380731<br /> x11: 000000000004058d x10: 0000000085a85b76<br /> x9 : ffff8000101436e4 x8 : ffff800011c8ce08<br /> x7 : 0000000000000000 x6 : 0000000000000001<br /> x5 : ffff0017df9ed338 x4 : 0000000000000001<br /> x3 : ffff8017ce62a000 x2 : ffff0017df9ed340<br /> x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> plist_check_prev_next_node+0x50/0x70<br /> plist_check_head+0x80/0xf0<br /> plist_add+0x28/0x140<br /> add_to_avail_list+0x9c/0xf0<br /> _enable_swap_info+0x78/0xb4<br /> __do_sys_swapon+0x918/0xa10<br /> __arm64_sys_swapon+0x20/0x30<br /> el0_svc_common+0x8c/0x220<br /> do_el0_svc+0x2c/0x90<br /> el0_svc+0x1c/0x30<br /> el0_sync_handler+0xa8/0xb0<br /> el0_sync+0x148/0x180<br /> irq event stamp: 2082270<br /> <br /> Now, si-&gt;lock locked before calling &amp;#39;del_from_avail_list()&amp;#39; to make sure<br /> other thread see the si had been deleted and SWP_WRITEOK cleared together,<br /> will not reinsert again.<br /> <br /> This problem exists in versions after stable 5.10.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix possible data races in gfs2_show_options()<br /> <br /> Some fields such as gt_logd_secs of the struct gfs2_tune are accessed<br /> without holding the lock gt_spin in gfs2_show_options():<br /> <br /> val = sdp-&gt;sd_tune.gt_logd_secs;<br /> if (val != 30)<br /> seq_printf(s, ",commit=%d", val);<br /> <br /> And thus can cause data races when gfs2_show_options() and other functions<br /> such as gfs2_reconfigure() are concurrently executed:<br /> <br /> spin_lock(&amp;gt-&gt;gt_spin);<br /> gt-&gt;gt_logd_secs = newargs-&gt;ar_commit;<br /> <br /> To fix these possible data races, the lock sdp-&gt;sd_tune.gt_spin is<br /> acquired before accessing the fields of gfs2_tune and released after these<br /> accesses.<br /> <br /> Further changes by Andreas:<br /> <br /> - Don&amp;#39;t hold the spin lock over the seq_printf operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memcontrol: ensure memcg acquired by id is properly set up<br /> <br /> In the eviction recency check, we attempt to retrieve the memcg to which<br /> the folio belonged when it was evicted, by the memcg id stored in the<br /> shadow entry. However, there is a chance that the retrieved memcg is not<br /> the original memcg that has been killed, but a new one which happens to<br /> have the same id.<br /> <br /> This is a somewhat unfortunate, but acceptable and rare inaccuracy in the<br /> heuristics. However, if we retrieve this new memcg between its allocation<br /> and when it is properly attached to the memcg hierarchy, we could run into<br /> the following NULL pointer exception during the memcg hierarchy traversal<br /> done in mem_cgroup_get_nr_swap_pages():<br /> <br /> [ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> [ 155757.807568] #PF: supervisor read access in kernel mode<br /> [ 155757.818024] #PF: error_code(0x0000) - not-present page<br /> [ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0<br /> [ 155757.839985] Oops: 0000 [#1] SMP<br /> [ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0<br /> [ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48<br /> [ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286<br /> [ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000<br /> [ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000<br /> [ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0<br /> [ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000<br /> [ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354<br /> [ 155758.019991] FS: 00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000<br /> [ 155758.036356] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0<br /> [ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 155758.091376] PKRU: 55555554<br /> [ 155758.096957] Call Trace:<br /> [ 155758.102016] <br /> [ 155758.106502] ? __die+0x78/0xc0<br /> [ 155758.112793] ? page_fault_oops+0x286/0x380<br /> [ 155758.121175] ? exc_page_fault+0x5d/0x110<br /> [ 155758.129209] ? asm_exc_page_fault+0x22/0x30<br /> [ 155758.137763] ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0<br /> [ 155758.148060] workingset_test_recent+0xda/0x1b0<br /> [ 155758.157133] workingset_refault+0xca/0x1e0<br /> [ 155758.165508] filemap_add_folio+0x4d/0x70<br /> [ 155758.173538] page_cache_ra_unbounded+0xed/0x190<br /> [ 155758.182919] page_cache_sync_ra+0xd6/0x1e0<br /> [ 155758.191738] filemap_read+0x68d/0xdf0<br /> [ 155758.199495] ? mlx5e_napi_poll+0x123/0x940<br /> [ 155758.207981] ? __napi_schedule+0x55/0x90<br /> [ 155758.216095] __x64_sys_pread64+0x1d6/0x2c0<br /> [ 155758.224601] do_syscall_64+0x3d/0x80<br /> [ 155758.232058] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 155758.242473] RIP: 0033:0x7f62c29153b5<br /> [ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b<br /> [ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011<br /> [ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5<br /> [ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076<br /> [ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c<br /> [ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041<br /> [ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450<br /> [ 155758.376661] <br /> <br /> This patch fixes the issue by moving the memcg&amp;#39;s id publication from the<br /> alloc stage to <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix soft lockup in status_resync<br /> <br /> status_resync() will calculate &amp;#39;curr_resync - recovery_active&amp;#39; to show<br /> user a progress bar like following:<br /> <br /> [============&gt;........] resync = 61.4%<br /> <br /> &amp;#39;curr_resync&amp;#39; and &amp;#39;recovery_active&amp;#39; is updated in md_do_sync(), and<br /> status_resync() can read them concurrently, hence it&amp;#39;s possible that<br /> &amp;#39;curr_resync - recovery_active&amp;#39; can overflow to a huge number. In this<br /> case status_resync() will be stuck in the loop to print a large amount<br /> of &amp;#39;=&amp;#39;, which will end up soft lockup.<br /> <br /> Fix the problem by setting &amp;#39;resync&amp;#39; to MD_RESYNC_ACTIVE in this case,<br /> this way resync in progress will be reported to user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: Avoid nf_ct_helper_hash uses after free<br /> <br /> If nf_conntrack_init_start() fails (for example due to a<br /> register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()<br /> clean-up path frees the nf_ct_helper_hash map.<br /> <br /> When built with NF_CONNTRACK=y, further netfilter modules (e.g:<br /> netfilter_conntrack_ftp) can still be loaded and call<br /> nf_conntrack_helpers_register(), independently of whether nf_conntrack<br /> initialized correctly. This accesses the nf_ct_helper_hash dangling<br /> pointer and causes a uaf, possibly leading to random memory corruption.<br /> <br /> This patch guards nf_conntrack_helper_register() from accessing a freed<br /> or uninitialized nf_ct_helper_hash pointer and fixes possible<br /> uses-after-free when loading a conntrack module.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject invalid reloc tree root keys with stack dump<br /> <br /> [BUG]<br /> Syzbot reported a crash that an ASSERT() got triggered inside<br /> prepare_to_merge().<br /> <br /> That ASSERT() makes sure the reloc tree is properly pointed back by its<br /> subvolume tree.<br /> <br /> [CAUSE]<br /> After more debugging output, it turns out we had an invalid reloc tree:<br /> <br /> BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17<br /> <br /> Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,<br /> QUOTA_TREE_OBJECTID), meaning it&amp;#39;s a reloc tree for quota tree.<br /> <br /> But reloc trees can only exist for subvolumes, as for non-subvolume<br /> trees, we just COW the involved tree block, no need to create a reloc<br /> tree since those tree blocks won&amp;#39;t be shared with other trees.<br /> <br /> Only subvolumes tree can share tree blocks with other trees (thus they<br /> have BTRFS_ROOT_SHAREABLE flag).<br /> <br /> Thus this new debug output proves my previous assumption that corrupted<br /> on-disk data can trigger that ASSERT().<br /> <br /> [FIX]<br /> Besides the dedicated fix and the graceful exit, also let tree-checker to<br /> check such root keys, to make sure reloc trees can only exist for subvolumes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: aspeed: socinfo: Add kfree for kstrdup<br /> <br /> Add kfree() in the later error handling in order to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix a null-ptr-deref in tipc_topsrv_accept<br /> <br /> syzbot found a crash in tipc_topsrv_accept:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> Workqueue: tipc_rcv tipc_topsrv_accept<br /> RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487<br /> Call Trace:<br /> <br /> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460<br /> process_one_work+0x991/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> It was caused by srv-&gt;listener that might be set to null by<br /> tipc_topsrv_stop() in net .exit whereas it&amp;#39;s still used in<br /> tipc_topsrv_accept() worker.<br /> <br /> srv-&gt;listener is protected by srv-&gt;idr_lock in tipc_topsrv_stop(), so add<br /> a check for srv-&gt;listener under srv-&gt;idr_lock in tipc_topsrv_accept() to<br /> avoid the null-ptr-deref. To ensure the lsock is not released during the<br /> tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()<br /> where it&amp;#39;s waiting until the tipc_topsrv_accept worker to be done.<br /> <br /> Note that sk_callback_lock is used to protect sk-&gt;sk_user_data instead of<br /> srv-&gt;listener, and it should check srv in tipc_topsrv_listener_data_ready()<br /> instead. This also ensures that no more tipc_topsrv_accept worker will be<br /> started after tipc_conn_close() is called in tipc_topsrv_stop() where it<br /> sets sk-&gt;sk_user_data to null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: avoid double -&gt;queue_rq() because of early timeout<br /> <br /> David Jeffery found one double -&gt;queue_rq() issue, so far it can<br /> be triggered in VM use case because of long vmexit latency or preempt<br /> latency of vCPU pthread or long page fault in vCPU pthread, then block<br /> IO req could be timed out before queuing the request to hardware but after<br /> calling blk_mq_start_request() during -&gt;queue_rq(), then timeout handler<br /> may handle it by requeue, then double -&gt;queue_rq() is caused, and kernel<br /> panic.<br /> <br /> So far, it is driver&amp;#39;s responsibility to cover the race between timeout<br /> and completion, so it seems supposed to be solved in driver in theory,<br /> given driver has enough knowledge.<br /> <br /> But it is really one common problem, lots of driver could have similar<br /> issue, and could be hard to fix all affected drivers, even it isn&amp;#39;t easy<br /> for driver to handle the race. So David suggests this patch by draining<br /> in-progress -&gt;queue_rq() for solving this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/hist: Fix out-of-bound write on &amp;#39;action_data.var_ref_idx&amp;#39;<br /> <br /> When generate a synthetic event with many params and then create a trace<br /> action for it [1], kernel panic happened [2].<br /> <br /> It is because that in trace_action_create() &amp;#39;data-&gt;n_params&amp;#39; is up to<br /> SYNTH_FIELDS_MAX (current value is 64), and array &amp;#39;data-&gt;var_ref_idx&amp;#39;<br /> keeps indices into array &amp;#39;hist_data-&gt;var_refs&amp;#39; for each synthetic event<br /> param, but the length of &amp;#39;data-&gt;var_ref_idx&amp;#39; is TRACING_MAP_VARS_MAX<br /> (current value is 16), so out-of-bound write happened when &amp;#39;data-&gt;n_params&amp;#39;<br /> more than 16. In this case, &amp;#39;data-&gt;match_data.event&amp;#39; is overwritten and<br /> eventually cause the panic.<br /> <br /> To solve the issue, adjust the length of &amp;#39;data-&gt;var_ref_idx&amp;#39; to be<br /> SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.<br /> <br /> [1]<br /> # cd /sys/kernel/tracing/<br /> # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\<br /> int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\<br /> int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\<br /> int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\<br /> int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\<br /> int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\<br /> int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\<br /> int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\<br /> int v63" &gt;&gt; synthetic_events<br /> # echo &amp;#39;hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"&amp;#39; &gt;&gt; \<br /> events/sched/sched_waking/trigger<br /> # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid)" &gt;&gt; events/sched/sched_switch/trigger<br /> <br /> [2]<br /> BUG: unable to handle page fault for address: ffff91c900000000<br /> PGD 61001067 P4D 61001067 PUD 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:strcmp+0xc/0x30<br /> Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee<br /> c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 b6 14<br /> 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3<br /> RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000<br /> RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000<br /> RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000<br /> R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580<br /> R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538<br /> FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> __find_event_file+0x55/0x90<br /> action_create+0x76c/0x1060<br /> event_hist_trigger_parse+0x146d/0x2060<br /> ? event_trigger_write+0x31/0xd0<br /> trigger_process_regex+0xbb/0x110<br /> event_trigger_write+0x6b/0xd0<br /> vfs_write+0xc8/0x3e0<br /> ? alloc_fd+0xc0/0x160<br /> ? preempt_count_add+0x4d/0xa0<br /> ? preempt_count_add+0x70/0xa0<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f1d1d0cf077<br /> Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e<br /> fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74<br /> RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077<br /> RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001<br /> RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142<br /> R<br /> ---truncated---