Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix OOB read in decode_watchers() via missing bounds check<br /> <br /> ceph_start_decoding() validates that struct_len bytes remain in the<br /> buffer after the encoding header, but accepts struct_len=0 as valid:<br /> ceph_decode_need(p, end, 0, bad) always passes. When a malicious or<br /> compromised OSD sends an obj_list_watch_response_t reply with<br /> struct_len=0, ceph_start_decoding() returns success with p == end,<br /> leaving zero bytes guaranteed for subsequent reads.<br /> <br /> The immediately following ceph_decode_32(p) in decode_watchers() has<br /> no preceding bounds check. With p == end this is a 4-byte read past<br /> the validated buffer boundary. The garbage value is then passed<br /> directly to kzalloc_objs() as the watcher count.<br /> <br /> The sibling function decode_watcher() already uses the safe variants<br /> (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32)<br /> after its own ceph_start_decoding() call. decode_watchers() is the<br /> only site that uses the bare variant, confirming an oversight.<br /> <br /> Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end,<br /> *num_watchers, bad), consistent with the established pattern.<br /> <br /> Attacker model: a malicious or compromised OSD in a multi-tenant Ceph<br /> deployment (e.g. cloud) can trigger this against any kernel client<br /> that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges<br /> beyond OSD session establishment.<br /> <br /> [ idryomov: trim changelog ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Fix out of bounds check on CCW array<br /> <br /> The routine ccwchain_calc_length() counts the number of channel<br /> command words (CCWs) that are chained together in a single channel<br /> program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs.<br /> <br /> The loop itself is "do..while (count

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Limit the number of channel program segments<br /> <br /> The processing of channel programs, and the CCWs within them, is done<br /> recursively. As such, there is an arbitrary (but not architectural)<br /> limit to the number of CCWs that can exist in a single channel program.<br /> <br /> The vfio-ccw logic breaks these channel programs into segments whenever<br /> it encounters a Transfer-In-Channel (TIC) CCW, and the combined number<br /> of segments count towards the global limit. Impose an equivalent limit<br /> to the number of segments until such logic can be made non-recursive.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Implement a crw lock<br /> <br /> Unlike the channel_program struct, which covers synchronous I/O<br /> submissions and asynchronous interrupts, the CRW region relies<br /> exclusively on asynchronous events coming from hardware.<br /> <br /> Implement a lock to manage the list of those payloads, to ensure<br /> they are read cohesively.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Selectively expand io_mutex<br /> <br /> The io_mutex was defined to serialize the io_regions, but then has<br /> also sort of been associated with the I/O themselves because of<br /> the close relationship they share.<br /> <br /> With the handful of races that are possible, the choices are either to:<br /> A) expand the scope of io_mutex to close these remaining windows, or<br /> B) reduce the scope of io_mutex to just io_region, and introduce a new<br /> lock mechanism for the remaining I/O resources<br /> <br /> This patch implements A, since B brings with it a lot more interactions<br /> that would need to be tracked and kept in a correct hierarchy. It also<br /> takes advantage of the workqueue element for cp_free() that now gets<br /> called out of fsm_notoper(), which could be invoked out of an interrupt<br /> context and thus cannot acquire a mutex itself.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Move cp cleanup out of not operational<br /> <br /> The fsm_notoper() routine is called when the device has been<br /> lost, and is (by definition) no longer operational. Since this<br /> can happen asynchronously from the normal behavior of the<br /> driver, the cleanup may happen when holding other locks<br /> in the calling sequence (notably, the cio subchannel lock).<br /> <br /> Push the cleanup of the private-&gt;cp resources to a workqueue,<br /> where it can be done out from under that lock sequence and<br /> a future patch can safely manage the locking requirements.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Ensure first IDAW remains constant<br /> <br /> The first IDAW in a list does not need to be on a 2K/4K boundary<br /> like all others, and so is read separately to accurately calculate<br /> the size of the buffer needed to read the full IDAL.<br /> <br /> Verify that the address found in the first IDAW is unchanged between<br /> reads, to ensure a consistent set of IDAWs being worked with.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Ensure index for read/write regions are within range<br /> <br /> The introduction of the capability chain rightly clamped the<br /> region indexes to the range of the capabilities itself, but<br /> neglected to do so for the existing read/write regions which<br /> should also be enforced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Cancel existing workqueues<br /> <br /> The initialization of the io_work and crw_work workqueues begs the<br /> question of whether they should be un-initialized. Add the corresponding<br /> cleanup tags in _release_dev to ensure work isn&amp;#39;t dispatched after<br /> the private struct is free&amp;#39;d.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank()<br /> <br /> amdgpu_dm_crtc_set_vblank() dereferences acrtc_state-&gt;stream when<br /> vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before<br /> a stream is attached to it.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu]<br /> Call Trace:<br /> drm_vblank_enable<br /> drm_vblank_get<br /> drm_crtc_get_sequence_ioctl<br /> drm_ioctl_kernel<br /> drm_ioctl<br /> <br /> Reproduced by running VKCTS with WSI tests enabled on RADV.<br /> <br /> Guard the enable path on acrtc_state-&gt;stream being non-NULL, matching<br /> the existing checks in this function.<br /> <br /> (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Pad trailing CCA or EP11 message with zeros<br /> <br /> The both functions xcrb_msg_to_type6cprb_msgx() and<br /> xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a<br /> kernel buffer based on the message length. But on further processing<br /> the message is supposed to be 4 byte length adjusted. Thus up to 3<br /> bytes of uninitialized kernel memory are forwarded to further<br /> processing steps and may unwanted expose kernel memory to the crypto<br /> card firmware.<br /> <br /> This patch contains code to pad the gap between user space copied<br /> message and message buffer length sent down to further processing of<br /> the CCA or EP11 message to zeros.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: propagate errors from xfs_rtginode_load<br /> <br /> xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than<br /> -ENOENT as success. This can leave the realtime group inode unset after an<br /> I/O, allocation, or corruption error. Growfs then continues as though the<br /> inode had been loaded.<br /> <br /> Only -ENOENT means that the inode needs to be created. Return all other<br /> errors to the growfs caller.