Vulnerabilidades

*** 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().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hackrf: fix to not free memory after the device is registered in hackrf_probe()<br /> <br /> In hackrf driver, the following race condition occurs:<br /> ```<br /> CPU0 CPU1<br /> hackrf_probe()<br /> kzalloc(); // alloc hackrf_dev<br /> ....<br /> v4l2_device_register();<br /> ....<br /> fd = sys_open("/path/to/dev"); // open hackrf fd<br /> ....<br /> v4l2_device_unregister();<br /> ....<br /> kfree(); // free hackrf_dev<br /> ....<br /> sys_ioctl(fd, ...);<br /> v4l2_ioctl();<br /> video_is_registered() // UAF!!<br /> ....<br /> sys_close(fd);<br /> v4l2_release() // UAF!!<br /> hackrf_video_release()<br /> kfree(); // DFB!!<br /> ```<br /> <br /> When a V4L2 or video device is unregistered, the device node is removed so<br /> new open() calls are blocked.<br /> <br /> However, file descriptors that are already open-and any in-flight I/O-do<br /> not terminate immediately; they remain valid until the last reference is<br /> dropped and the driver&amp;#39;s release() is invoked.<br /> <br /> Therefore, freeing device memory on the error path after hackrf_probe()<br /> has registered dev it will lead to a race to use-after-free vuln, since<br /> those already-open handles haven&amp;#39;t been released yet.<br /> <br /> And since release() free memory too, race to use-after-free and<br /> double-free vuln occur.<br /> <br /> To prevent this, if device is registered from probe(), it should be<br /> modified to free memory only through release() rather than calling<br /> kfree() directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map<br /> <br /> The DAT inode&amp;#39;s btree node cache (i_assoc_inode) is initialized lazily<br /> during btree operations. However, nilfs_mdt_save_to_shadow_map()<br /> assumes i_assoc_inode is already initialized when copying dirty pages<br /> to the shadow map during GC.<br /> <br /> If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before<br /> any btree operation has occurred on the DAT inode, i_assoc_inode is<br /> NULL leading to a general protection fault.<br /> <br /> Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode<br /> in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always<br /> initialized before any GC operation can use it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: as102: fix to not free memory after the device is registered in as102_usb_probe()<br /> <br /> In as102_usb driver, the following race condition occurs:<br /> ```<br /> CPU0 CPU1<br /> as102_usb_probe()<br /> kzalloc(); // alloc as102_dev_t<br /> ....<br /> usb_register_dev();<br /> fd = sys_open("/path/to/dev"); // open as102 fd<br /> ....<br /> usb_deregister_dev();<br /> ....<br /> kfree(); // free as102_dev_t<br /> ....<br /> sys_close(fd);<br /> as102_release() // UAF!!<br /> as102_usb_release()<br /> kfree(); // DFB!!<br /> ```<br /> <br /> When a USB character device registered with usb_register_dev() is later<br /> unregistered (via usb_deregister_dev() or disconnect), the device node is<br /> removed so new open() calls fail. However, file descriptors that are<br /> already open do not go away immediately: they remain valid until the last<br /> reference is dropped and the driver&amp;#39;s .release() is invoked.<br /> <br /> In as102, as102_usb_probe() calls usb_register_dev() and then, on an<br /> error path, does usb_deregister_dev() and frees as102_dev_t right away.<br /> If userspace raced a successful open() before the deregistration, that<br /> open FD will later hit as102_release() --&gt; as102_usb_release() and access<br /> or free as102_dev_t again, occur a race to use-after-free and<br /> double-free vuln.<br /> <br /> The fix is to never kfree(as102_dev_t) directly once usb_register_dev()<br /> has succeeded. After deregistration, defer freeing memory to .release().<br /> <br /> In other words, let release() perform the last kfree when the final open<br /> FD is closed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit<br /> <br /> wg_netns_pre_exit() manually acquires rtnl_lock() inside the<br /> pernet .pre_exit callback. This causes a hung task when another<br /> thread holds rtnl_mutex - the cleanup_net workqueue (or the<br /> setup_net failure rollback path) blocks indefinitely in<br /> wg_netns_pre_exit() waiting to acquire the lock.<br /> <br /> Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:<br /> Add -&gt;exit_rtnl() hook to struct pernet_operations."), where the<br /> framework already holds RTNL and batches all callbacks under a<br /> single rtnl_lock()/rtnl_unlock() pair, eliminating the contention<br /> window.<br /> <br /> The rcu_assign_pointer(wg-&gt;creating_net, NULL) is safe to move<br /> from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())<br /> because all RCU readers of creating_net either use maybe_get_net()<br /> - which returns NULL for a dying namespace with zero refcount - or<br /> access net-&gt;user_ns which remains valid throughout the entire<br /> ops_undo_list sequence.<br /> <br /> [ Jason: added __net_exit and __read_mostly annotations that were missing. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fix cached_dev.sb_bio use-after-free and crash<br /> <br /> In our production environment, we have received multiple crash reports<br /> regarding libceph, which have caught our attention:<br /> <br /> ```<br /> [6888366.280350] Call Trace:<br /> [6888366.280452] blk_update_request+0x14e/0x370<br /> [6888366.280561] blk_mq_end_request+0x1a/0x130<br /> [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]<br /> [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]<br /> [6888366.280903] __complete_request+0x22/0x70 [libceph]<br /> [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]<br /> [6888366.281164] ? inet_recvmsg+0x5b/0xd0<br /> [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]<br /> [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]<br /> [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]<br /> [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]<br /> ```<br /> <br /> After analyzing the coredump file, we found that the address of<br /> dc-&gt;sb_bio has been freed. We know that cached_dev is only freed when it<br /> is stopped.<br /> <br /> Since sb_bio is a part of struct cached_dev, rather than an alloc every<br /> time. If the device is stopped while writing to the superblock, the<br /> released address will be accessed at endio.<br /> <br /> This patch hopes to wait for sb_write to complete in cached_dev_free.<br /> <br /> It should be noted that we analyzed the cause of the problem, then tell<br /> all details to the QWEN and adopted the modifications it made.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: 6fire: fix use-after-free on disconnect<br /> <br /> In usb6fire_chip_abort(), the chip struct is allocated as the card&amp;#39;s<br /> private data (via snd_card_new with sizeof(struct sfire_chip)). When<br /> snd_card_free_when_closed() is called and no file handles are open, the<br /> card and embedded chip are freed synchronously. The subsequent<br /> chip-&gt;card = NULL write then hits freed slab memory.<br /> <br /> Call trace:<br /> usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline]<br /> usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182<br /> usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458<br /> ...<br /> hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953<br /> <br /> Fix by moving the card lifecycle out of usb6fire_chip_abort() and into<br /> usb6fire_chip_disconnect(). The card pointer is saved in a local<br /> before any teardown, snd_card_disconnect() is called first to prevent<br /> new opens, URBs are aborted while chip is still valid, and<br /> snd_card_free_when_closed() is called last so chip is never accessed<br /> after the card may be freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (powerz) Fix use-after-free on USB disconnect<br /> <br /> After powerz_disconnect() frees the URB and releases the mutex, a<br /> subsequent powerz_read() call can acquire the mutex and call<br /> powerz_read_data(), which dereferences the freed URB pointer.<br /> <br /> Fix by:<br /> - Setting priv-&gt;urb to NULL in powerz_disconnect() so that<br /> powerz_read_data() can detect the disconnected state.<br /> - Adding a !priv-&gt;urb check at the start of powerz_read_data()<br /> to return -ENODEV on a disconnected device.<br /> - Moving usb_set_intfdata() before hwmon registration so the<br /> disconnect handler can always find the priv pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib<br /> <br /> amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence<br /> from amdgpu_ib_schedule(). This fence is used to wait for job<br /> completion.<br /> <br /> Currently, the code drops the fence reference using dma_fence_put()<br /> before calling dma_fence_wait().<br /> <br /> If dma_fence_put() releases the last reference, the fence may be<br /> freed before dma_fence_wait() is called. This can lead to a<br /> use-after-free.<br /> <br /> Fix this by waiting on the fence first and releasing the reference<br /> only after dma_fence_wait() completes.<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory &amp;#39;f&amp;#39; (line 696)<br /> <br /> (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)