Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: use uninterruptible resv lock for plane updates<br /> <br /> virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock<br /> the framebuffer BO&amp;#39;s dma_resv via virtio_gpu_array_lock_resv() and<br /> ignore its return value. The function can fail with -EINTR from<br /> dma_resv_lock_interruptible() (signal during lock wait) or with<br /> -ENOMEM from dma_resv_reserve_fences() (fence slot allocation),<br /> leaving the resv lock not held. The queue path then walks the object<br /> array and calls dma_resv_add_fence(), which requires the lock held;<br /> with lockdep enabled this trips dma_resv_assert_held():<br /> <br /> WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840<br /> Call Trace:<br /> virtio_gpu_array_add_fence<br /> virtio_gpu_queue_ctrl_sgs<br /> virtio_gpu_queue_fenced_ctrl_buffer<br /> virtio_gpu_cursor_plane_update<br /> drm_atomic_helper_commit_planes<br /> drm_atomic_helper_commit_tail<br /> commit_tail<br /> drm_atomic_helper_commit<br /> drm_atomic_commit<br /> drm_atomic_helper_update_plane<br /> __setplane_atomic<br /> drm_mode_cursor_universal<br /> drm_mode_cursor_common<br /> drm_mode_cursor_ioctl<br /> drm_ioctl<br /> __x64_sys_ioctl<br /> <br /> Beyond the WARN, mutating the dma_resv fence list without the lock<br /> races with concurrent readers/writers and can corrupt the list.<br /> <br /> Both call sites run inside the .atomic_update plane callback, which<br /> DRM atomic helpers do not allow to fail (by the time it runs, the<br /> commit has been signed off to userspace and there is no clean<br /> rollback path). Moving the lock acquisition to .prepare_fb was<br /> rejected because the broader lock scope deadlocks against other BO<br /> locking paths in the same atomic commit.<br /> <br /> Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses<br /> dma_resv_lock() instead of dma_resv_lock_interruptible(). This<br /> eliminates the -EINTR failure mode -- the realistic syzbot trigger<br /> -- without extending the lock hold across the commit. The helper<br /> locks a single BO and rejects nents &gt; 1 with -EINVAL; both fix<br /> sites lock exactly one BO.<br /> <br /> Use it from virtio_gpu_cursor_plane_update() and<br /> virtio_gpu_resource_flush(); check the return value to handle the<br /> remaining -ENOMEM case from dma_resv_reserve_fences() by freeing<br /> the objs and skipping the plane update for that frame. The<br /> framebuffer BOs touched here are not shared with other contexts<br /> and lock contention is expected to be brief, so the loss of<br /> signal-interruptibility is acceptable.<br /> <br /> Other callers of virtio_gpu_array_lock_resv() (the ioctl paths)<br /> continue to use the interruptible variant.<br /> <br /> The bug was reported by syzbot, triggered via fault injection<br /> (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the<br /> -ENOMEM branch in dma_resv_reserve_fences().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix use-after-free of CPU job query arrays on error path<br /> <br /> The CPU job ioctl&amp;#39;s fail label calls kvfree() on cpu_job&amp;#39;s timestamp and<br /> performance query arrays after v3d_job_cleanup(), which drops the job&amp;#39;s<br /> last reference and frees cpu_job. Reading cpu_job at that point is a<br /> use-after-free. Also, on the early v3d_job_init() failure path, it is a<br /> NULL dereference, since v3d_job_deallocate() zeroes the local pointer.<br /> <br /> In the success path, the arrays are released from the scheduler&amp;#39;s<br /> .free_job callback, but on the error path, they are freed manually, as<br /> the job was never pushed to the scheduler. While the success path deals<br /> with this correctly, the fail path doesn&amp;#39;t.<br /> <br /> On top of that, the manual kvfree() calls only free the array storage;<br /> they don&amp;#39;t drm_syncobj_put() the per-query syncobjs that<br /> v3d_timestamp_query_info_free() and v3d_performance_query_info_free()<br /> release on the success path. So the same fail path that triggers the<br /> use-after-free also leaks one syncobj reference per query.<br /> <br /> Unify the CPU job teardown into the CPU job&amp;#39;s kref destructor, mirroring<br /> v3d_render_job_free(). The scheduler&amp;#39;s .free_job slot reverts to the<br /> generic v3d_sched_job_free() and the fail label drops the manual<br /> kvfree() calls, leaving a single teardown path that is reached from both<br /> the scheduler and the ioctl error path. That removes the use-after-free,<br /> the NULL dereference, and the syncobj leak by construction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer<br /> <br /> adm1266_pmbus_block_xfer() copies the device-supplied block payload<br /> into the caller-provided buffer using the device-supplied length:<br /> <br /> memcpy(data_r, &amp;msgs[1].buf[1], msgs[1].buf[0]);<br /> <br /> The helper does not know how large data_r is and trusts the device to<br /> return at most one record&amp;#39;s worth of bytes. adm1266_nvmem_read_blackbox()<br /> violates that contract: it advances read_buff inside data-&gt;dev_mem in<br /> ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to<br /> write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns<br /> more than 64 bytes on the trailing record (read_buff offset 1984 in<br /> the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes<br /> before the post-call<br /> <br /> if (ret != ADM1266_BLACKBOX_SIZE)<br /> return -EIO;<br /> <br /> can reject the response.<br /> <br /> Contain the fix in the caller without changing the helper signature:<br /> read each record into a 255-byte local bounce buffer that matches the<br /> helper&amp;#39;s maximum output, validate the returned length, and only then<br /> copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) reject implausible blackbox record_count<br /> <br /> adm1266_nvmem_read_blackbox() loops over a record_count that comes<br /> straight from byte 3 of the BLACKBOX_INFO response. The destination<br /> buffer is data-&gt;dev_mem, sized for the nvmem cell&amp;#39;s declared 2048<br /> bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64).<br /> A device that reports a record_count greater than 32 -- whether due<br /> to firmware bugs, bus corruption, or a non-responsive slave returning<br /> 0xff -- would walk read_buff past the end of the dev_mem allocation<br /> on the trailing iterations.<br /> <br /> Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here)<br /> before entering the loop and return -EIO on any larger value, so a<br /> malformed BLACKBOX_INFO response cannot drive the loop out of bounds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: avoid empty VLAN responses<br /> <br /> The commit 16116dac2339 ("batman-adv: prevent TT request storms by not<br /> sending inconsistent TT TLVLs") added checks to the local (direct) TT<br /> response code. But the response can also be done indirectly by another node<br /> using the global TT state. To avoid such inconsistency states reported in<br /> the original fix, also avoid sending empty VLANs for replies from the<br /> global TT state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR<br /> <br /> adm1266_gpio_get_multiple() iterates the PDIO portion of the<br /> caller-supplied mask using<br /> <br /> for_each_set_bit_from(gpio_nr, mask,<br /> ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) {<br /> ...<br /> }<br /> <br /> where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233),<br /> not the number of PDIO pins. The intended upper bound is<br /> ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25.<br /> <br /> gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip),<br /> so the iteration walks find_next_bit() up to 242, reading up to 217<br /> extra bits (a handful of unsigned-long words: four on 64-bit, seven<br /> on 32-bit) of whatever lives past the end of the mask in the<br /> caller&amp;#39;s stack. Any incidental set bit in that range then drives a<br /> set_bit(gpio_nr, bits) call that writes past the end of the<br /> caller-supplied bits array too -- both out-of-bounds.<br /> <br /> Substitute ADM1266_PDIO_NR for the constant so the scan stops at the<br /> last real PDIO bit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer<br /> <br /> adm1266_pmbus_block_xfer() sets up the read transaction with<br /> <br /> .buf = data-&gt;read_buf,<br /> .len = ADM1266_PMBUS_BLOCK_MAX + 2,<br /> <br /> but read_buf in struct adm1266_data is declared as<br /> <br /> u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1];<br /> <br /> For a max-length block response (length byte = 255 + up to 1 PEC<br /> byte), the i2c controller is told to write 257 bytes into a 256-byte<br /> buffer, putting one byte past the end of read_buf. The same response<br /> also makes the subsequent PEC compare<br /> <br /> if (crc != msgs[1].buf[msgs[1].buf[0] + 1])<br /> <br /> read a byte beyond the array.<br /> <br /> Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the<br /> buffer can hold the length byte, up to 255 payload bytes, and the PEC<br /> byte the i2c_msg length already accounts for.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix negative tt_buff_len<br /> <br /> batadv_orig_node::tt_buff_len was declared as s16, but the field is never<br /> intended to hold a negative value. When a value greater than 32767 is<br /> assigned, it wraps to a negative signed integer.<br /> <br /> In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to<br /> s32. The incorrectly negative s16 value propagates into the s32, causing<br /> batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but<br /> populates only a small portion of it with the collected changeset. All<br /> remaining bits are kept uninitialized.<br /> <br /> Using an u16 avoids this type confusion and ensures that no (negative) sign<br /> extension is performed in batadv_send_other_tt_response().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix negative last_changeset_len<br /> <br /> batadv_piv_tt::last_changeset_len len was declared as s16, but the field is<br /> never intended to hold a negative value. When a value greater than 32767 is<br /> assigned, it wraps to a negative signed integer.<br /> <br /> In batadv_send_my_tt_response(), last_changeset_len is temporarily widened<br /> to s32. The incorrectly negative s16 value propagates into the s32, causing<br /> batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but<br /> populates only a small portion of it with the collected changeset. All<br /> remaining bits are kept uninitialized.<br /> <br /> Using an u16 avoids this type confusion and ensures that no (negative) sign<br /> extension is performed in batadv_send_my_tt_response().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix TOCTOU race for reported vlans<br /> <br /> The local TT based TVLV is generated by first checking the number of VLANs<br /> which have at least one TT entry. A new buffer with the correct size for<br /> the VLANs is then allocated. Only then, the list of VLANs s used to fill<br /> the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock<br /> is held. But the actual number of TT entries of each VLAN can still<br /> increase during this time - just not the number of VLANs in the list.<br /> <br /> But the prefilter used in the buffer size calculation might still cause an<br /> increase of the number of VLANs which need to be stored. Simply because a<br /> VLAN might now suddenly have at least one entry when it had none in the<br /> pre-alloc check - and then needs to occupy space which was not allocated.<br /> <br /> It is better to overestimate the buffer size at the beginning and then fill<br /> the buffer only with the VLANs which are not empty.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fprobe: Fix unregister_fprobe() to wait for RCU grace period<br /> <br /> Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")<br /> changed fprobe to register struct fprobe to an rcu-hlist, but it forgot<br /> to wait for RCU GP. Thus there can be use-after-free if the fprobe is<br /> released right after unregistering. This can be happened on fprobe<br /> event and sample module code.<br /> <br /> To fix this issue, add synchronize_rcu() in unregister_fprobe().<br /> <br /> Note that BPF is OK because fprobe is used as a part of<br /> bpf_kprobe_multi_link. This unregisters its fprobe in<br /> bpf_kprobe_multi_link_release() and it is deallocated via<br /> bpf_kprobe_multi_link_dealloc(), which is invoked from<br /> bpf_link_defer_dealloc_rcu_gp() RCU callback.<br /> <br /> For BPF, this also introduced unregister_fprobe_async() which does<br /> NOT wait for RCU grace priod.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: allocate hook ops while under mutex<br /> <br /> arp/ip(6)t_register_table() add the table to the per-netns list via<br /> xt_register_table() before allocating the per-netns hook ops copy<br /> via kmemdup_array(). This leaves a window where the table is<br /> visible in the list with ops=NULL.<br /> <br /> If the pernet exit happens runs concurrently the pre_exit callback finds<br /> the table via xt_find_table() and passes the NULL ops pointer to<br /> nf_unregister_net_hooks(), causing a NULL dereference:<br /> <br /> general protection fault in nf_unregister_net_hooks+0xbc/0x150<br /> RIP: nf_unregister_net_hooks (net/netfilter/core.c:613)<br /> Call Trace:<br /> ipt_unregister_table_pre_exit<br /> iptable_mangle_net_pre_exit<br /> ops_pre_exit_list<br /> cleanup_net<br /> <br /> Fix by moving the ops allocation into the xtables core so the table is<br /> never in the list without valid ops. Also ensure the table is no longer<br /> processing packets before its torn down on error unwind.<br /> nf_register_net_hooks might have published at least one hook; call<br /> synchronize_rcu() if there was an error.<br /> <br /> audit log register message gets deferred until all operations have<br /> passed, this avoids need to emit another ureg message in case of<br /> error unwinding.<br /> <br /> Based on earlier patch by Tristan Madani.