Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask()<br /> <br /> Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask()<br /> stacking") introduced refcount-based GFP mask management that warns<br /> when pm_restore_gfp_mask() is called with saved_gfp_count == 0.<br /> <br /> Some hibernation paths call pm_restore_gfp_mask() defensively where<br /> the GFP mask may or may not be restricted depending on the execution<br /> path. For example, the uswsusp interface invokes it in<br /> SNAPSHOT_CREATE_IMAGE, SNAPSHOT_UNFREEZE, and snapshot_release().<br /> Before the stacking change this was a silent no-op; it now triggers<br /> a spurious WARNING.<br /> <br /> Remove the WARN_ON() wrapper from the !saved_gfp_count check while<br /> retaining the check itself, so that defensive calls remain harmless<br /> without producing false warnings.<br /> <br /> [ rjw: Subject tweak ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Add missing secure storage access fixups for donated memory<br /> <br /> There are special cases where secure storage access exceptions happen<br /> in a kernel context for pages that don&amp;#39;t have the PG_arch_1 bit<br /> set. That bit is set for non-exported guest secure storage (memory)<br /> but is absent on storage donated to the Ultravisor since the kernel<br /> isn&amp;#39;t allowed to export donated pages.<br /> <br /> Prior to this patch we would try to export the page by calling<br /> arch_make_folio_accessible() which would instantly return since the<br /> arch bit is absent signifying that the page was already exported and<br /> no further action is necessary. This leads to secure storage access<br /> exception loops which can never be resolved.<br /> <br /> With this patch we unconditionally try to export and if that fails we<br /> fixup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Handle the case that EIOINTC&amp;#39;s coremap is empty<br /> <br /> EIOINTC&amp;#39;s coremap in eiointc_update_sw_coremap() can be empty, currently<br /> we get a cpuid with -1 in this case, but we actually need 0 because it&amp;#39;s<br /> similar as the case that cpuid &gt;= 4.<br /> <br /> This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gw: fix OOB heap access in cgw_csum_crc8_rel()<br /> <br /> cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():<br /> <br /> int from = calc_idx(crc8-&gt;from_idx, cf-&gt;len);<br /> int to = calc_idx(crc8-&gt;to_idx, cf-&gt;len);<br /> int res = calc_idx(crc8-&gt;result_idx, cf-&gt;len);<br /> <br /> if (from result_idx] = ...; /* BUG: raw negative index */<br /> <br /> With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,<br /> calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with<br /> i = -64, reading cf-&gt;data[-64], and the write goes to cf-&gt;data[-64].<br /> This write might end up to 56 (7.0-rc) or 40 (