Threats Tagged 'cve-2026-43233'

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() (CVE-2026-43206) * kernel: drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4 (CVE-2026-43237) * kernel: crypto: pcrypt - Fix handling of MAY_BACKLOG requests (CVE-2026-43493) * kernel: udf: fix partition descriptor append bookkeeping (CVE-2026-45991) * kernel: drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 (CVE-2026-45878) * kernel: smb/client: fix out-of-bounds read in symlink_data() (CVE-2026-46185) * kernel: sched/psi: fix race between file release and pressure write (CVE-2026-52991) * kernel: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 (CVE-2026-53143) * kernel: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size (CVE-2026-53136) * kernel: drm/amd/display: Use krealloc_array() in dal_vector_reserve() (CVE-2026-53329) * kernel: drm/i915/gem: Fix phys BO pread/pwrite with offset (CVE-2026-53356) * kernel: drm/amdgpu: zero-initialize GART table on allocation (CVE-2026-53374) * kernel: drm/i915: Fix potential UAF in TTM object purge (CVE-2026-63884) * kernel: scsi: target: iscsi: Validate CHAP_R length before base64 decode (CVE-2026-63886) * kernel: memfd: deny writeable mappings when implying SEAL_WRITE (CVE-2026-63952) * kernel: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() (CVE-2026-63888) * kernel: blk-mq: pop cached request if it is usable (CVE-2026-64017) * kernel: drm/amdgpu: fix amdgpu_hmm_range_get_pages (CVE-2026-63879) * kernel: drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async (CVE-2026-64219) * kernel: smb: client: fix double-free in SMB2_open() replay (CVE-2026-64382) * kernel: smb: client: mask server-provided mode to 07777 in modefromsid (CVE-2026-64379) * kernel: smb: client: fix query_info() replay double-free (CVE-2026-64386) * kernel: posix-cpu-timers: Prevent UAF caused by non-leader exec() race (CVE-2026-64560) * kernel: smb/client: handle overlapping allocated ranges in fallocate (CVE-2026-68388) Bug Fix(es) and Enhancement(s): * CLONE - RHEL 10.2.z xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN (JIRA:RHEL-223954) * vhost: reset the vring metadata cache on vring reconfiguration [rhel-10.2.z] (JIRA:RHEL-224545) * cifs: periodic IO errors when rename races with lease break [rhel-10.2.z] (JIRA:RHEL-235459) * cifs: smb1 directory listings from xp server returning EINVAL and EIO [rhel-10.2.z] (JIRA:RHEL-235812) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().