Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: avoid double decrement of bla.num_requests<br /> <br /> The bla.num_requests is increased when no request_sent was in progress. And<br /> it is decremented in various places (announcement was received, backbone is<br /> purged, periodic work). But the check if the request_sent is actually set<br /> to a specific state and the atomic_dec/_inc are not safe because they are<br /> not atomic (TOCTOU) and multiple such code portions can run concurrently.<br /> <br /> At the same time, it is necessary to modify request_sent (state) and<br /> bla.num_requests atomically. Otherwise batadv_bla_send_request() might set<br /> request_sent to 1 and is interrupted. batadv_handle_announce() can then<br /> set request_sent back to 0 and decrement num_requests before<br /> batadv_bla_send_request() incremented it.<br /> <br /> The two operations must therefore be locked. And since state (request_sent)<br /> and wait_periods are only accessed inside this lock, they can be converted<br /> to simpler datatypes. And to avoid that the bla.num_requests is touched by<br /> a parallel running context with a valid backbone_gw reference after<br /> batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to<br /> correctly signal that a backbone_gw is in the state of being cleaned up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: mcast: fix use-after-free in orig_node RCU release<br /> <br /> batadv_mcast_purge_orig() removes entries from RCU-protected hlists but<br /> does not wait for an RCU grace period before returning. Concurrent RCU<br /> readers may still accesses references to those entries at the point of<br /> removal. RCU-protected readers trying to operate on entries like<br /> orig-&gt;mcast_want_all_ipv6_node will then access already freed memory.<br /> <br /> Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(),<br /> just before the call_rcu() invocation. This ensures RCU readers that were<br /> active at purge time have drained before the orig_node memory is reclaimed.

*** 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 /> drm/amd/display: Validate GPIO pin LUT table size before iterating<br /> <br /> [Why&amp;How]<br /> The GPIO pin table parsers in get_gpio_i2c_info() and<br /> bios_parser_get_gpio_pin_info() derive an element count from the VBIOS<br /> table_header.structuresize field, then iterate over gpio_pin[] entries.<br /> However, GET_IMAGE() only validates that the table header itself fits<br /> within the BIOS image. If the VBIOS reports a structuresize larger than<br /> the actual mapped data, the loop reads past the end of the BIOS image,<br /> causing an out-of-bounds read.<br /> <br /> Fix this by calling bios_get_image() to validate that the full claimed<br /> structuresize is accessible within the BIOS image before entering the<br /> loop in both functions.<br /> <br /> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown<br /> <br /> The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is<br /> responsible for releasing the tp_vars reference it holds. However, the<br /> existing logic for coordinating this release with batadv_tp_stop_all() was<br /> flawed.<br /> <br /> timer_shutdown_sync() guarantees the timer will not fire again after it<br /> returns, but it returns non-zero only when the timer was pending at the<br /> time of the call. If the timer had already expired (and<br /> batadv_tp_stop_all() would unsucessfully try to rearm itself),<br /> batadv_tp_stop_all() skips its batadv_tp_vars_put(), and<br /> batadv_tp_receiver_shutdown() fails to put its own reference as well.<br /> <br /> Fix this by introducing a new atomic variable receiving that is set to 1<br /> when the receiver is initialized and cleared atomically with atomic_xchg()<br /> by whichever side claims it first. Only the side that observes the<br /> transition from 1 to 0 is responsible for releasing the tp_vars timer<br /> reference, eliminating the uncertainty.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface<br /> <br /> Without rtnl_lock held, a hardif might be retrieved as primary interface of<br /> a meshif, but then (while operating on this interface) getting decoupled<br /> from the mesh interface. In this case, the meshif still exists but the<br /> pointer from the primary hardif to the meshif is set to NULL.<br /> <br /> The mesh_iface must be checked first to be non-NULL before continuing to<br /> send an ARP request using meshif.

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