Red Hat Linux Security Advisories & CVEs
5788 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.
Official source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat advisories
Medium [CVE-2026-78475] Gimp: unbounded stack vla and 21-byte stack over-read in pix (esm) loader
A flaw was found in the file-pix (ESM) plugin in GIMP. When processing a specially crafted PIX image file, the plugin allocates a Variable-Length Array (VLA) on the stack without proper bounds checking, causing an unbounded stack allocation followed by a 21-byte stack over-read. This can result in a denial of service due to stack exhaustion and a limited information disclosure of stack memory contents into an intermediate file. To exploit this vulnerability, an attacker needs to convince a user to process a specially crafted PIX image with GIMP, reducing the likelihood of exploitation. Due to this reason, this flaw has been rated with a moderate severity. Red Hat severity: Moderate — CVSS 6.1 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: gimp.
Medium [CVE-2026-76845] Arbitrary File Overwrite via Symlink Following
adm-zip 0.5.9 through 0.6.0 follows symbolic links at the extraction destination. When a path component at the destination already exists as a symbolic link pointing outside the extraction root, extractAllTo, extractAllToAsync and extractEntryTo write the entry contents through that link and then chmod its target, placing attacker-controlled content in a file outside the root without any traversal sequence appearing in the archive. Reaching the write requires overwrite to be enabled, because the preceding fs.existsSync check also resolves the link and otherwise declines. An attacker able to create a symbolic link inside a shared, reused or predictable extraction directory, such as a temporary directory or a continuous integration workspace, can overwrite any file the extracting process is permitted to write. A flaw was found in `adm-zip`, a Node.js library used for handling zip archives. This vulnerability allows a local attacker to overwrite arbitrary files on the system. An attacker can exploit this by placing a symbolic link within a temporary extraction directory, redirecting the extraction process to write data outside the intended secure location. This could lead to unauthorized modification of system files. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N). Weakness: CWE-59.
Medium [CVE-2026-78323] JSSTrustManager does not verify NSS trust flags on CA certificates
A flaw was found in JSS (Java Security Services). The JSSTrustManager class does not verify NSS trust flags when validating CA certificates, allowing certificates present in the NSS database without TRUSTED_CA flags to be accepted as trust anchors for TLS connections. In non-default configurations where certificate revocation checking is disabled, this could allow a man-in-the-middle attacker to forge certificates accepted by PKI client connections. This flaw exists in the JSSTrustManager class but is mitigated in default product configurations by the native revocation verification check. Exploitation requires non-default configuration changes (disabling certificate revocation verification) that are not documented or recommended. The server-side TLS validation path (TomcatJSS) uses a different trust manager (JSSNativeTrustManager) that properly delegates to NSS native verification and is not affected. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N). Weakness: CWE-295. Affected Red Hat products: Red Hat Certificate System 10; Red Hat Certificate System 11; Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9. Red Hat lists Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8 as not affected. Will not fix / out of support: Red Hat Enterprise Linux 6.
Medium [CVE-2026-10618] Stored Cross-Site Scripting via unescaped code-fence attribute values
Hugo's default fenced-code-block renderer writes attribute values taken from the code-fence info string into the rendered HTML without escaping them. New in markup/internal/attributes/attributes.go converts every attribute value from a byte slice to a string as it is stored, deliberately dropping the escaping that used to happen there, and RenderAttributes in the same file escapes only values that are still byte slices, so its escaping branch is never reached and every value is written verbatim. The function's documentation states that it performs HTML escaping of string attributes, which it does not. A quote inside an attribute value in the info string therefore terminates the attribute and allows a further attribute, including an event handler, to be placed on the wrapper element, and the script runs for every visitor who loads the page. This path is reached under the default configuration, with code fences enabled and without goldmark's unsafe setting or any custom render hook. Attribute names beginning with on are filtered when the attributes are parsed, so injection is achieved through the value rather than the name. This vulnerability allows a remote attacker to inject arbitrary script code into the rendered HTML by providing specially crafted input in the code-fence info string.
Medium [CVE-2026-59295] Micrometer Instrumentation for Apache HttpAsyncClient: Denial of Service via asynchronous request failures
Micrometer-instrumented Apache HttpAsyncClient (4.x or 5.x) usage via MicrometerHttpClientInterceptor can leak memory unboundedly when asynchronous requests fail before receiving a response (e.g. connection resets or timeouts). Tracking state for these requests remains in memory indefinitely, and sustained failures lead to heap exhaustion and OutOfMemoryError crashes. A flaw was found in Micrometer Instrumentation for Apache HttpAsyncClient. This continuous memory leak leads to heap exhaustion and OutOfMemoryError crashes, resulting in a Denial of Service (DoS) for the affected application. This Moderate severity flaw impacts Red Hat products utilizing Micrometer-instrumented Apache HttpAsyncClient. The vulnerability can lead to a denial of service due to unbounded memory growth when asynchronous requests fail before a response is received. Exploitation requires specific network conditions or failures, making the attack complexity high. Weakness: CWE-772. Affected Red Hat products: Red Hat AMQ Broker 7; Red Hat build of Quarkus.
Medium [CVE-2026-70626] Information disclosure via symlink escape in CorpusReader.open
NLTK versions before 3.9.4 contain a symlink escape vulnerability in CorpusReader.open() that allows local attackers to read arbitrary files outside the corpus root. The vulnerability exists because path validation is lexical and does not account for symlink resolution, enabling attackers to place symlinks inside the corpus root to access files outside the intended boundary. A flaw was found in NLTK. By placing symbolic links (symlinks) within the corpus root, an attacker can bypass path validation in the `CorpusReader.open()` function, which does not properly account for symlink resolution. This could lead to unauthorized information disclosure. The vulnerability arises from improper path validation in CorpusReader.open() when handling symlinks, enabling an attacker with local access to bypass security restrictions and access sensitive data. This affects components within Red Hat Ansible Automation Platform and Red Hat OpenShift AI that utilize the vulnerable NLTK library. Red Hat severity: Moderate — CVSS 6.2 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-22. Red Hat lists Exploit Intelligence; Lightspeed Core; OpenShift Lightspeed; Red Hat Ansible Automation Platform 2; Red Hat OpenShift AI (RHOAI) as not affected.
Medium [CVE-2026-65915] Arbitrary file read due to logic bug in FileSystemPathPointer
NLTK versions before 3.10.0 contain a logic bug in FileSystemPathPointer.open() where the sandbox validation check compares a normalized path against itself, making the security check permanently inert. Attackers can pass file:// URLs to nltk.data.load() to read arbitrary files accessible to the process user, including credentials and configuration files. A flaw was found in NLTK. A remote attacker can exploit this by providing specially crafted `file://` Uniform Resource Locators (URLs) to `nltk.data.load()`. This enables the attacker to read arbitrary files on the system, potentially leading to the disclosure of sensitive information such as credentials and configuration files. This could lead to information disclosure, including sensitive credentials or configuration data, within affected Red Hat products such as Lightspeed Core, OpenShift Lightspeed, Red Hat Ansible Automation Platform, and Red Hat OpenShift AI. Exploitation requires the application to process untrusted input that can be interpreted as a `file://` URL by NLTK. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-22. Red Hat lists OpenShift Lightspeed as not affected. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Exploit Intelligence; Red Hat Ansible Automation Platform 2; Red Hat OpenShift AI (RHOAI).
Medium [CVE-2026-63311] Server-Side Request Forgery bypass via DNS resolution failures
NLTK before 3.10.0 (affected versions <= 3.9.4) contains a server-side request forgery (SSRF) vulnerability in the validate_network_url() function in nltk/pathsec.py. The _resolve_hostname() helper catches OSError and ValueError during socket.getaddrinfo() and returns an empty list; when DNS resolution fails, the validation loop executes no IP checks and the function fails open, allowing urlopen() to proceed without validation. An attacker who can trigger DNS resolution failures or use DNS rebinding can bypass SSRF protections and reach restricted network resources, including cloud metadata endpoints (e.g., 169.254.169.254). A flaw was found in NLTK. This server-side request forgery (SSRF) vulnerability allows an attacker to bypass network access restrictions. By triggering DNS resolution failures or using DNS rebinding, an attacker can cause the `validate_network_url()` function to incorrectly validate URLs. This flaw in NLTK allows a server-side request forgery (SSRF) bypass when DNS resolution fails or through DNS rebinding. This could enable an attacker to access restricted internal network resources, including cloud metadata endpoints, within Red Hat environments utilizing affected NLTK versions. Red Hat severity: Moderate — CVSS 4.2 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N). Weakness: CWE-918.
Medium [CVE-2026-62385] Information disclosure through path traversal
NLTK versions before 3.10.0 contain a path traversal vulnerability in FramenetCorpusReader and NKJPCorpusReader that allows attackers to parse XML files outside the corpus root by supplying unsafe selectors or poisoned index state. Attackers can exploit frame_by_name, doc, lu, and header methods with crafted parameters to read arbitrary XML files accessible to the application. A flaw was found in NLTK. This path traversal vulnerability, located in the FramenetCorpusReader and NKJPCorpusReader components, allows an attacker to read arbitrary XML files accessible to the application. This can be achieved by supplying unsafe selectors or poisoned index state, exploiting methods such as `frame_by_name`, `doc`, `lu`, and `header` with specially crafted parameters. The primary consequence is information disclosure. Successful exploitation requires an application to process specially crafted input through the vulnerable NLTK components. Red Hat severity: Moderate — CVSS 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-22. Red Hat lists Exploit Intelligence; Lightspeed Core; OpenShift Lightspeed; Red Hat Ansible Automation Platform 2; Red Hat OpenShift AI (RHOAI) as not affected.
Medium [CVE-2026-62383] Information disclosure via symlink in IPIPANCorpusReader
nltk versions before 3.10.2 contain a symlink-based arbitrary file read vulnerability in IPIPANCorpusReader methods that bypass nltk.pathsec validation entirely. Attackers can place a symlink in the corpus root directory and read arbitrary files accessible to the process by calling channels(), domains(), categories(), or fileids() methods with the symlink filename. A flaw was found in nltk. A local attacker can exploit a symlink-based vulnerability in the IPIPANCorpusReader methods. By placing a symbolic link in the corpus root directory and invoking specific methods, an attacker can bypass security validation and read arbitrary files accessible to the process. This could lead to unauthorized information disclosure. The `nltk` library is vulnerable to information disclosure, allowing an attacker with local access and low privileges to read arbitrary files. This occurs if an attacker can place a symlink within the `nltk` corpus root directory, bypassing path validation and enabling access to sensitive data with the permissions of the running process. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-22. Red Hat lists Exploit Intelligence; Lightspeed Core; OpenShift Lightspeed; Red Hat Ansible Automation Platform 2; Red Hat OpenShift AI (RHOAI) as not affected.
Medium [CVE-2026-62380] Null byte and CRLF injection in SOCKS client encoders can lead to domain spoofing
Netty (io.netty:netty-codec-socks) versions 4.2.0.Final through 4.2.16.Final and 4.1.x through 4.1.136.Final contain null byte, CRLF, and credential injection vulnerabilities in the SOCKS4 (Socks4ClientEncoder) and SOCKS5 (Socks5ClientEncoder) client encoders, which fail to validate domain address and authentication (username/password) fields. An attacker able to control these fields can inject null bytes or CRLF characters to truncate or alter values, potentially enabling domain spoofing, SOCKS4 userid truncation, authentication data injection, and protocol confusion. Fixed in 4.2.17.Final and 4.1.137.Final. This vulnerability allows a remote attacker to inject null bytes or Carriage Return Line Feed (CRLF) characters into domain address and authentication fields due to insufficient validation. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). Weakness: CWE-93. Affected products named by the advisory: Exploit Intelligence; OpenShift Serverless; Red Hat AMQ Broker 7; Red Hat build of Apache Camel 4 for Quarkus 3; and 14 more.
Medium [CVE-2026-74584] zero shared page before exposing to userspace
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: zero shared page before exposing to userspace bnxt_re_alloc_ucontext() allocates uctx->shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it. The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents. Any user with access to /dev/infiniband/uverbsX on a host with a bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT. Other shared pages in the same file already use get_zeroed_page() correctly: drivers/infiniband/hw/bnxt_re/ib_verbs.c srq->uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL); cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL); uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page(). A local attacker with access to the RDMA device could exploit this vulnerability due to a failure to zero out a shared memory page before exposing it to userspace.
Medium [CVE-2026-74595] use the mount idmap for the owner check in fscrypt_ioctl_set_policy
In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead. This vulnerability can lead to legitimate users being denied access to set encryption policies, while unauthorized users might be wrongly permitted to do so, resulting in an access control bypass. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-628. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74607] Serialize accesses to the owner and mirror list with separate lock
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.
Medium [CVE-2026-74625] release template ct on non-IP path
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: release template ct on non-IP path A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path. This vulnerability allows for a memory leak when the system processes non-IPv4 and non-IPv6 network traffic through a bridge nftables connection tracking rule. The system fails to release an existing connection tracking template reference, leading to a gradual accumulation of unreleased memory. This can ultimately result in a denial of service (DoS) condition as the host runs out of available memory. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-74638] Serialize the scheduler timeout handlers
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Serialize the scheduler timeout handlers V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs.
Medium [CVE-2026-74729] Fix usercopy overflow in snoop_file_read
In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)! kernel BUG at mm/usercopy.c! Call trace: usercopy_abort __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer). Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock. A flaw was found in the Linux kernel's Aspeed Low Pin Count (LPC) snoop driver. This vulnerability arises from a lack of synchronization during concurrent access to a kernel First-In, First-Out (kfifo) buffer.
Medium [CVE-2026-74664] reallocate update replies for mismatched IDs
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails. A flaw was found in the Linux kernel's Open vSwitch component. When processing flow updates, the `ovs_flow_cmd_new()` function preallocates a reply buffer based on the request's flow identifier.
Medium [CVE-2026-74683] evdev - sanitize event type index when fetching event masks
In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. This could lead to speculative execution mispredicting bounds checks and performing out-of-bounds loads, potentially resulting in information disclosure. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74712] Fix buffer length in create_direct_keys
In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [ ] cmd_exec+0x550/0xca0 [mlx5_core] [ ] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [ ] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [ ] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size. This vulnerability occurs due to an incorrect calculation of buffer length within the `create_direct_keys()` function, causing the system to read beyond its allocated memory boundaries.