Vulnerabilities

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

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)

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.

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.

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.

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.

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.

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.

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.

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

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

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.