Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish<br /> <br /> Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as<br /> allowing userspace to manipulate and/or run a vCPU while its state is being<br /> synchronized would at best corrupt vCPU state, and at worst crash the host<br /> kernel.<br /> <br /> Opportunistically assert that vcpu-&gt;mutex is held when synchronizing its<br /> VMSA (the SEV-ES path already locks vCPUs).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm-&gt;lock<br /> <br /> Take and hold kvm-&gt;lock for before checking sev_guest() in<br /> sev_mem_enc_register_region(), as sev_guest() isn&amp;#39;t stable unless kvm-&gt;lock<br /> is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can&amp;#39;t<br /> rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to<br /> a not-yet-initialized sev-&gt;regions_list, e.g. triggering a #GP<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024<br /> RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83<br /> Code: 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00<br /> RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256<br /> RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000<br /> RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000<br /> R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000<br /> R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000<br /> FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371<br /> kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363<br /> __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f34e9f7e9a9<br /> Code: 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9<br /> RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007<br /> RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8<br /> <br /> <br /> with a syzlang reproducer that looks like:<br /> <br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000040)={0x0, &amp;(0x7f0000000180)=ANY=[], 0x70}) (async)<br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000080)={0x0, &amp;(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async)<br /> r0 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000200), 0x0, 0x0)<br /> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)<br /> r2 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000240), 0x0, 0x0)<br /> r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)<br /> ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &amp;(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)<br /> ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &amp;(0x7f0000000280)={[...], 0x5}) (async)<br /> ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)<br /> r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)<br /> openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)<br /> ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &amp;(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &amp;(0x7f0000001000/0x2000)=nil}) (async)<br /> r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)<br /> close(r0) (async)<br /> openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000000), 0x8000, 0x0) (async)<br /> ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &amp;(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)<br /> ioctl$KVM_RUN(r5, 0xae80, 0x0)<br /> <br /> Opportunistically use guard() to avoid having to define a new error label<br /> and goto usage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU<br /> <br /> Reject synchronizing vCPU state to its associated VMSA if the vCPU has<br /> already been launched, i.e. if the VMSA has already been encrypted. On a<br /> host with SNP enabled, accessing guest-private memory generates an RMP #PF<br /> and panics the host.<br /> <br /> BUG: unable to handle page fault for address: ff1276cbfdf36000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x80000003) - RMP violation<br /> PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163<br /> SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f]<br /> Oops: Oops: 0003 [#1] SMP NOPTI<br /> CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023<br /> RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]<br /> Call Trace:<br /> <br /> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd]<br /> snp_launch_finish+0xb6/0x380 [kvm_amd]<br /> sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd]<br /> kvm_arch_vm_ioctl+0x837/0xcf0 [kvm]<br /> kvm_vm_ioctl+0x3fd/0xcc0 [kvm]<br /> __x64_sys_ioctl+0xa3/0x100<br /> x64_sys_call+0xfe0/0x2350<br /> do_syscall_64+0x81/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7ffff673287d<br /> <br /> <br /> Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM:<br /> Provide support to launch and run an SEV-ES guest"), but has only been<br /> actively dangerous for the host since SNP support was added. With SEV-ES,<br /> KVM would "just" clobber guest state, which is totally fine from a host<br /> kernel perspective since userspace can clobber guest state any time before<br /> sev_launch_update_vmsa().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: call -&gt;free_folio() directly in folio_unmap_invalidate()<br /> <br /> We can only call filemap_free_folio() if we have a reference to (or hold a<br /> lock on) the mapping. Otherwise, we&amp;#39;ve already removed the folio from the<br /> mapping so it no longer pins the mapping and the mapping can be removed,<br /> causing a use-after-free when accessing mapping-&gt;a_ops.<br /> <br /> Follow the same pattern as __remove_mapping() and load the free_folio<br /> function pointer before dropping the lock on the mapping. That lets us<br /> make filemap_free_folio() static as this was the only caller outside<br /> filemap.c.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: em28xx: fix use-after-free in em28xx_v4l2_open()<br /> <br /> em28xx_v4l2_open() reads dev-&gt;v4l2 without holding dev-&gt;lock,<br /> creating a race with em28xx_v4l2_init()&amp;#39;s error path and<br /> em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct<br /> and set dev-&gt;v4l2 to NULL under dev-&gt;lock.<br /> <br /> This race leads to two issues:<br /> - use-after-free in v4l2_fh_init() when accessing vdev-&gt;ctrl_handler,<br /> since the video_device is embedded in the freed em28xx_v4l2 struct.<br /> - NULL pointer dereference in em28xx_resolution_set() when accessing<br /> v4l2-&gt;norm, since dev-&gt;v4l2 has been set to NULL.<br /> <br /> Fix this by moving the mutex_lock() before the dev-&gt;v4l2 read and<br /> adding a NULL check for dev-&gt;v4l2 under the lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix use-after-free in encoder release path<br /> <br /> The fops_vcodec_release() function frees the context structure (ctx)<br /> without first cancelling any pending or running work in ctx-&gt;encode_work.<br /> This creates a race window where the workqueue handler (mtk_venc_worker)<br /> may still be accessing the context memory after it has been freed.<br /> <br /> Race condition:<br /> <br /> CPU 0 (release path) CPU 1 (workqueue)<br /> --------------------- ------------------<br /> fops_vcodec_release()<br /> v4l2_m2m_ctx_release()<br /> v4l2_m2m_cancel_job()<br /> // waits for m2m job "done"<br /> mtk_venc_worker()<br /> v4l2_m2m_job_finish()<br /> // m2m job "done"<br /> // BUT worker still running!<br /> // post-job_finish access:<br /> other ctx dereferences<br /> // UAF if ctx already freed<br /> // returns (job "done")<br /> kfree(ctx) // ctx freed<br /> <br /> Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job<br /> lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle.<br /> After v4l2_m2m_job_finish() is called, the m2m framework considers<br /> the job complete and v4l2_m2m_ctx_release() returns, but the worker<br /> function continues executing and may still access ctx.<br /> <br /> The work is queued during encode operations via:<br /> queue_work(ctx-&gt;dev-&gt;encode_workqueue, &amp;ctx-&gt;encode_work)<br /> The worker function accesses ctx-&gt;m2m_ctx, ctx-&gt;dev, and other ctx<br /> fields even after calling v4l2_m2m_job_finish().<br /> <br /> This vulnerability was confirmed with KASAN by running an instrumented<br /> test module that widens the post-job_finish race window. KASAN detected:<br /> <br /> BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180<br /> Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12<br /> <br /> Workqueue: mtk_vcodec_enc_wq mtk_venc_worker<br /> <br /> Allocated by task 47:<br /> __kasan_kmalloc+0x7f/0x90<br /> fops_vcodec_open+0x85/0x1a0<br /> <br /> Freed by task 47:<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0xee/0x3a0<br /> fops_vcodec_release+0xb7/0x190<br /> <br /> Fix this by calling cancel_work_sync(&amp;ctx-&gt;encode_work) before kfree(ctx).<br /> This ensures the workqueue handler is both cancelled (if pending) and<br /> synchronized (waits for any running handler to complete) before the<br /> context is freed.<br /> <br /> Placement rationale: The fix is placed after v4l2_ctrl_handler_free()<br /> and before list_del_init(&amp;ctx-&gt;list). At this point, all m2m operations<br /> are done (v4l2_m2m_ctx_release() has returned), and we need to ensure<br /> the workqueue is synchronized before removing ctx from the list and<br /> freeing it.<br /> <br /> Note: The open error path does NOT need cancel_work_sync() because<br /> INIT_WORK() only initializes the work structure - it does not schedule<br /> it. Work is only scheduled later during device_run() operations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: fix nfeeds state corruption on start_streaming failure<br /> <br /> syzbot reported a memory leak in vidtv_psi_service_desc_init [1].<br /> <br /> When vidtv_start_streaming() fails inside vidtv_start_feed(), the<br /> nfeeds counter is left incremented even though no feed was actually<br /> started. This corrupts the driver state: subsequent start_feed calls<br /> see nfeeds &gt; 1 and skip starting the mux, while stop_feed calls<br /> eventually try to stop a non-existent stream.<br /> <br /> This state corruption can also lead to memory leaks, since the mux<br /> and channel resources may be partially allocated during a failed<br /> start_streaming but never cleaned up, as the stop path finds<br /> dvb-&gt;streaming == false and returns early.<br /> <br /> Fix by decrementing nfeeds back when start_streaming fails, keeping<br /> the counter in sync with the actual number of active feeds.<br /> <br /> [1]<br /> BUG: memory leak<br /> unreferenced object 0xffff888145b50820 (size 32):<br /> comm "syz.0.17", pid 6068, jiffies 4294944486<br /> backtrace (crc 90a0c7d4):<br /> vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288<br /> vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83<br /> vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524<br /> vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]<br /> vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()<br /> <br /> cgwb_release_workfn() calls css_put(wb-&gt;blkcg_css) and then later accesses<br /> wb-&gt;blkcg_css again via blkcg_unpin_online(). If css_put() drops the last<br /> reference, the blkcg can be freed asynchronously (css_free_rwork_fn -&gt;<br /> blkcg_css_free -&gt; kfree) before blkcg_unpin_online() dereferences the<br /> pointer to access blkcg-&gt;online_pin, resulting in a use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)<br /> Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531<br /> Workqueue: cgwb_release cgwb_release_workfn<br /> Call Trace:<br /> <br /> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)<br /> cgwb_release_workfn (mm/backing-dev.c:629)<br /> process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385)<br /> <br /> Freed by task 1016:<br /> kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561)<br /> css_free_rwork_fn (kernel/cgroup/cgroup.c:5542)<br /> process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)<br /> <br /> ** Stack based on commit 66672af7a095 ("Add linux-next specific files<br /> for 20260410")<br /> <br /> I am seeing this crash sporadically in Meta fleet across multiple kernel<br /> versions. A full reproducer is available at:<br /> https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh<br /> <br /> (The race window is narrow. To make it easily reproducible, inject a<br /> msleep(100) between css_put() and blkcg_unpin_online() in<br /> cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the<br /> reproducer triggers the splat reliably in less than a second.)<br /> <br /> Fix this by moving blkcg_unpin_online() before css_put(), so the<br /> cgwb&amp;#39;s CSS reference keeps the blkcg alive while blkcg_unpin_online()<br /> accesses it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6apm: move component registration to unmanaged version<br /> <br /> q6apm component registers dais dynamically from ASoC toplology, which<br /> are allocated using device managed version apis. Allocating both<br /> component and dynamic dais using managed version could lead to incorrect<br /> free ordering, dai will be freed while component still holding references<br /> to it.<br /> <br /> Fix this issue by moving component to unmanged version so<br /> that the dai pointers are only freeded after the component is removed.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core]<br /> Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426<br /> Tainted: [W]=WARN<br /> Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024<br /> Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface]<br /> Call trace:<br /> show_stack+0x28/0x7c (C)<br /> dump_stack_lvl+0x60/0x80<br /> print_report+0x160/0x4b4<br /> kasan_report+0xac/0xfc<br /> __asan_report_load8_noabort+0x20/0x34<br /> snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core]<br /> snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core]<br /> devm_component_release+0x30/0x5c [snd_soc_core]<br /> devres_release_all+0x13c/0x210<br /> device_unbind_cleanup+0x20/0x190<br /> device_release_driver_internal+0x350/0x468<br /> device_release_driver+0x18/0x30<br /> bus_remove_device+0x1a0/0x35c<br /> device_del+0x314/0x7f0<br /> device_unregister+0x20/0xbc<br /> apr_remove_device+0x5c/0x7c [apr]<br /> device_for_each_child+0xd8/0x160<br /> apr_pd_status+0x7c/0xa8 [apr]<br /> pdr_notifier_work+0x114/0x240 [pdr_interface]<br /> process_one_work+0x500/0xb70<br /> worker_thread+0x630/0xfb0<br /> kthread+0x370/0x6c0<br /> ret_from_fork+0x10/0x20<br /> <br /> Allocated by task 77:<br /> kasan_save_stack+0x40/0x68<br /> kasan_save_track+0x20/0x40<br /> kasan_save_alloc_info+0x44/0x58<br /> __kasan_kmalloc+0xbc/0xdc<br /> __kmalloc_node_track_caller_noprof+0x1f4/0x620<br /> devm_kmalloc+0x7c/0x1c8<br /> snd_soc_register_dai+0x50/0x4f0 [snd_soc_core]<br /> soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core]<br /> snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core]<br /> audioreach_tplg_init+0x124/0x1fc [snd_q6apm]<br /> q6apm_audio_probe+0x10/0x1c [snd_q6apm]<br /> snd_soc_component_probe+0x5c/0x118 [snd_soc_core]<br /> soc_probe_component+0x44c/0xaf0 [snd_soc_core]<br /> snd_soc_bind_card+0xad0/0x2370 [snd_soc_core]<br /> snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core]<br /> devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core]<br /> x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100]<br /> platform_probe+0xc0/0x188<br /> really_probe+0x188/0x804<br /> __driver_probe_device+0x158/0x358<br /> driver_probe_device+0x60/0x190<br /> __device_attach_driver+0x16c/0x2a8<br /> bus_for_each_drv+0x100/0x194<br /> __device_attach+0x174/0x380<br /> device_initial_probe+0x14/0x20<br /> bus_probe_device+0x124/0x154<br /> deferred_probe_work_func+0x140/0x220<br /> process_one_work+0x500/0xb70<br /> worker_thread+0x630/0xfb0<br /> kthread+0x370/0x6c0<br /> ret_from_fork+0x10/0x20<br /> <br /> Freed by task 3426:<br /> kasan_save_stack+0x40/0x68<br /> kasan_save_track+0x20/0x40<br /> __kasan_save_free_info+0x4c/0x80<br /> __kasan_slab_free+0x78/0xa0<br /> kfree+0x100/0x4a4<br /> devres_release_all+0x144/0x210<br /> device_unbind_cleanup+0x20/0x190<br /> device_release_driver_internal+0x350/0x468<br /> device_release_driver+0x18/0x30<br /> bus_remove_device+0x1a0/0x35c<br /> device_del+0x314/0x7f0<br /> device_unregister+0x20/0xbc<br /> apr_remove_device+0x5c/0x7c [apr]<br /> device_for_each_child+0xd8/0x160<br /> apr_pd_status+0x7c/0xa8 [apr]<br /> pdr_notifier_work+0x114/0x240 [pdr_interface]<br /> process_one_work+0x500/0xb70<br /> worker_thread+0x630/0xfb0<br /> kthread+0x370/0x6c0<br /> ret_from_fork+0x10/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Use scratch field in MMIO fragment to hold small write values<br /> <br /> When exiting to userspace to service an emulated MMIO write, copy the<br /> to-be-written value to a scratch field in the MMIO fragment if the size<br /> of the data payload is 8 bytes or less, i.e. can fit in a single chunk,<br /> instead of pointing the fragment directly at the source value.<br /> <br /> This fixes a class of use-after-free bugs that occur when the emulator<br /> initiates a write using an on-stack, local variable as the source, the<br /> write splits a page boundary, *and* both pages are MMIO pages. Because<br /> KVM&amp;#39;s ABI only allows for physically contiguous MMIO requests, accesses<br /> that split MMIO pages are separated into two fragments, and are sent to<br /> userspace one at a time. When KVM attempts to complete userspace MMIO in<br /> response to KVM_RUN after the first fragment, KVM will detect the second<br /> fragment and generate a second userspace exit, and reference the on-stack<br /> variable.<br /> <br /> The issue is most visible if the second KVM_RUN is performed by a separate<br /> task, in which case the stack of the initiating task can show up as truly<br /> freed data.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420<br /> Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984<br /> <br /> CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:<br /> dump_stack+0xbe/0xfd<br /> print_address_description.constprop.0+0x19/0x170<br /> __kasan_report.cold+0x6c/0x84<br /> kasan_report+0x3a/0x50<br /> check_memory_region+0xfd/0x1f0<br /> memcpy+0x20/0x60<br /> complete_emulated_mmio+0x305/0x420<br /> kvm_arch_vcpu_ioctl_run+0x63f/0x6d0<br /> kvm_vcpu_ioctl+0x413/0xb20<br /> __se_sys_ioctl+0x111/0x160<br /> do_syscall_64+0x30/0x40<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> RIP: 0033:0x42477d<br /> Code: 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d<br /> RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005<br /> RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c<br /> R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720<br /> <br /> The buggy address belongs to the page:<br /> page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37<br /> flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ==================================================================<br /> <br /> The bug can also be reproduced with a targeted KVM-Unit-Test by hacking<br /> KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by<br /> overwrite the data value with garbage.<br /> <br /> Limit the use of the scratch fields to 8-byte or smaller accesses, and to<br /> just writes, as larger accesses and reads are not affected thanks to<br /> implementation details in the emulator, but add a sanity check to ensure<br /> those details don&amp;#39;t change in the future. Specifically, KVM never uses<br /> on-stack variables for accesses larger that 8 bytes, e.g. uses an operand<br /> in the emulator context, and *al<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clockevents: Add missing resets of the next_event_forced flag<br /> <br /> The prevention mechanism against timer interrupt starvation missed to reset<br /> the next_event_forced flag in a couple of places:<br /> <br /> - When the clock event state changes. That can cause the flag to be<br /> stale over a shutdown/startup sequence<br /> <br /> - When a non-forced event is armed, which then prevents rearming before<br /> that event. If that event is far out in the future this will cause<br /> missed timer interrupts.<br /> <br /> - In the suspend wakeup handler.<br /> <br /> That led to stalls which have been reported by several people.<br /> <br /> Add the missing resets, which fixes the problems for the reporters.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/userfaultfd: fix hugetlb fault mutex hash calculation<br /> <br /> In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the<br /> page index for hugetlb_fault_mutex_hash(). However, linear_page_index()<br /> returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()<br /> expects the index in huge page units. This mismatch means that different<br /> addresses within the same huge page can produce different hash values,<br /> leading to the use of different mutexes for the same huge page. This can<br /> cause races between faulting threads, which can corrupt the reservation<br /> map and trigger the BUG_ON in resv_map_release().<br /> <br /> Fix this by introducing hugetlb_linear_page_index(), which returns the<br /> page index in huge page granularity, and using it in place of<br /> linear_page_index().