huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
ublk: make sure ubq->canceling is set when queue is frozen
CVE: CVE-2025-22068
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 7.4/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ublk: make sure ubq->canceling is set when queue is frozen

Now ublk driver depends on `ubq->canceling` for deciding if the request
can be dispatched via uring_cmd & io_uring_cmd_complete_in_task().

Once ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd()
and io_uring_cmd_done().

So set ubq->canceling when queue is frozen, this way makes sure that the
flag can be observed from ublk_queue_rq() reliably, and avoids
use-after-free on uring_cmd.

Statement: Red Hat Enterprise Linux and Fedora not affected (all versions). For triggering the bug user needs to have access to the kind of ioctl requests for the ublk driver.

Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
xorg-x11-server: tigervnc: Integer Overflow in Big Requests Extension
CVE: CVE-2025-49176
Component: xorg-x11-server-Xwayland
CWE: CWE-190
Severity: Important
CVSS v3: 7.5/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H
Release date: 2025-06-17T00:00:00+00:00

A flaw was found in the Big Requests extension. The request length is multiplied by 4 before checking against the maximum allowed size, potentially causing an integer overflow and bypassing the size check.

Statement: This vulnerability is rated as an important severity because this flaw exists in the Big Requests extension of the X.Org X server, where the length of client requests is multiplied by 4 before validating against the maximum allowed size. This computation can cause an integer overflow when a sufficiently large length value is provided, resulting in a wrapped-around total length that appears valid to the size check logic, leading to out-of-bounds memory access, successful exploitation can cause denial of service by crashing the server and may permit memory corruption, compromising system integrity and availability.

Remediation:
Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
neurobin shc os command injection
CVE: CVE-2025-9174
Component: shc
CVSS v3: 5.4/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-08-19T22:32:08.348000+00:00

An os command injection flaw has been discovered in neurobin shc. The `make` function in the `src/shc.c` file does not properly handle user input, which may lead to command injection. This vulnerability requires local access in order to exploit.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
REXML denial of service
CVE: CVE-2025-58767
Component: rexml
CWE: CWE-776
Severity: Moderate
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-09-17T17:45:58.118000+00:00

A denial of service flaw has been discovered in the rubygem REXML. Certain input can cause excess cpu usage and given sufficiently large input this can affect program performance.

Statement: Red Hat Product Security team has rated this vulnerability as having the 'Moderate' severity, with the final CVSSv3.1 score of 5.3 as the final impact in availability is restricted to the application consuming the REXML package and not the whole system.

Remediation:
The primary mitigation for this flaw is to avoid parsing XML documents originating from untrusted, unauthenticated, or unverified sources.
NVIDIA Nsight Visual Studio for Windows: Arbitrary Code Execution and Privilege Escalation in Nsight Monitor
CVE: CVE-2025-33229
Component: nsight-systems
CWE: CWE-427
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:H
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in NVIDIA Nsight Visual Studio for Windows, specifically within the Nsight Monitor component. An attacker can exploit this vulnerability to execute arbitrary code with the same privileges as the Nsight Monitor application. This can lead to escalation of privileges, allowing the attacker to gain higher access, execute unauthorized code, tamper with data, cause a denial of service, or disclose sensitive information.

Statement: This vulnerability is rated Important as when it is installed on Red Hat Enterprise Linux, it is susceptible to arbitrary code execution with the privileges of the monitor application. Exploitation requires local access and user interaction.

Remediation:
usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal
CVE: CVE-2025-68781
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal

The delayed work item otg_event is initialized in fsl_otg_conf() and
scheduled under two conditions:
1. When a host controller binds to the OTG controller.
2. When the USB ID pin state changes (cable insertion/removal).

A race condition occurs when the device is removed via fsl_otg_remove():
the fsl_otg instance may be freed while the delayed work is still pending
or executing. This leads to use-after-free when the work function
fsl_otg_event() accesses the already freed memory.

The problematic scenario:

(detach thread)            | (delayed work)
fsl_otg_remove()           |
  kfree(fsl_otg_dev) //FREE| fsl_otg_event()
                           |   og = container_of(...) //USE
                           |   og-> //USE

Fix this by calling disable_delayed_work_sync() in fsl_otg_remove()
before deallocating the fsl_otg structure. This ensures the delayed work
is properly canceled and completes execution prior to memory deallocation.

This bug was identified through static analysis.


Remediation:
drm/xe: Fix tlb invalidation when wedging
CVE: CVE-2025-21644
Component: kernel
CWE: CWE-476
Severity: Low
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix tlb invalidation when wedging

If GuC fails to load, the driver wedges, but in the process it tries to
do stuff that may not be initialized yet. This moves the
xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,
it's a software-only initialization and should had been named with the
_early() suffix.

Move it to be called by xe_gt_init_early(), so the locks and seqno are
initialized, avoiding a NULL ptr deref when wedging:

	xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01
	xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed
	xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.
	...
	BUG: kernel NULL pointer dereference, address: 0000000000000000
	#PF: supervisor read access in kernel mode
	#PF: error_code(0x0000) - not-present page
	PGD 0 P4D 0
	Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
	CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G     U  W          6.13.0-rc4-xe+ #3
	Tainted: [U]=USER, [W]=WARN
	Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022
	RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]

This can be easily triggered by poking the GuC binary to force a
signature failure. There will still be an extra message,

	xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100

but that's better than a NULL ptr deref.

(cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)


Remediation:
WebAssembly wabt Malformed File binary-reader-interp.cc OnExport heap-based overflow
CVE: CVE-2025-2368
Component: wabt
CWE: CWE-122
Severity: Moderate
CVSS v3: 6.2/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
Release date: 2025-03-17T08:00:05.922000+00:00

A vulnerability was found in WebAssembly wabt 1.0.36 and classified as critical. This issue affects the function wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnExport of the file wabt/src/interp/binary-reader-interp.cc of the component Malformed File Handler. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.


Remediation:
net: mctp: Set SOCK_RCU_FREE
CVE: CVE-2025-37790
Component: kernel
Severity: None
Release date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: mctp: Set SOCK_RCU_FREE

Bind lookup runs under RCU, so ensure that a socket doesn't go away in
the middle of a lookup.


Remediation:
firefox: Use-after-free in MediaTrackGraphImpl::GetInstance()
CVE: CVE-2025-11708
Component: thunderbird
CWE: CWE-416
Severity: Important
CVSS v3: 7.5/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-10-14T12:27:35.228000+00:00

A flaw was found in Thunderbird and Firefox. The Mozilla Foundation's Security Advisory describes the following issue:
Use-after-free in MediaTrackGraphImpl::GetInstance()

Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.

Remediation:
netlink: Fix wraparounds of sk->sk_rmem_alloc.
CVE: CVE-2025-38465
Component: kernel
CWE: CWE-190
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-07-25T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

netlink: Fix wraparounds of sk->sk_rmem_alloc.

Netlink has this pattern in some places

  if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
  	atomic_add(skb->truesize, &sk->sk_rmem_alloc);

, which has the same problem fixed by commit 5a465a0da13e ("udp:
Fix multiple wraparounds of sk->sk_rmem_alloc.").

For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition
is always false as the two operands are of int.

Then, a single socket can eat as many skb as possible until OOM
happens, and we can see multiple wraparounds of sk->sk_rmem_alloc.

Let's fix it by using atomic_add_return() and comparing the two
variables as unsigned int.

Before:
  [root@fedora ~]# ss -f netlink
  Recv-Q      Send-Q Local Address:Port                Peer Address:Port
  -1668710080 0               rtnl:nl_wraparound/293               *

After:
  [root@fedora ~]# ss -f netlink
  Recv-Q     Send-Q Local Address:Port                Peer Address:Port
  2147483072 0               rtnl:nl_wraparound/290               *
  ^
  `--- INT_MAX - 576


Remediation:
Thor Command Injection Vulnerability
CVE: CVE-2025-54314
Component: thor
CWE: CWE-78
Severity: Low
CVSS v3: 2.7/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
Release date: 2025-07-20T00:00:00+00:00

A flaw was found in Thor, where it improperly constructs shell commands using data derived from libraries. This flaw allows a local attacker to execute arbitrary commands. Command execution occurs when processing specially crafted library input.


Remediation:
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE: CVE-2025-30405
Component: CVE-2025-30405
Release date: 2025-01-01T00:00:00+00:00

An integer overflow vulnerability in the loading of ExecuTorch models can cause objects to be placed outside their allocated memory area, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 0830af8207240df8d7f35b984cdf8bc35d74fa73.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
Mailgen: HTML injection vulnerability in plaintext e-mails
CVE: CVE-2025-59526
Component: mailgen
Release date: 2025-09-22T19:27:53.323000+00:00

mailgen is a Node.js package that generates responsive HTML e-mails for sending transactional mail. Prior to version 2.0.30, there is an HTML injection vulnerability in plaintext e-mails generated by Mailgen. Projects are affected if the Mailgen.generatePlaintext(email) method is used and given user-generated content. This vulnerability has been patched in version 2.0.30. A workaround involves stripping all HTML tags before passing any content into Mailgen.generatePlaintext(email).

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
drm/amdkfd: Don't call mmput from MMU notifier callback
CVE: CVE-2025-38520
Component: kernel
Severity: None
Release date: 2025-08-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Don't call mmput from MMU notifier callback

If the process is exiting, the mmput inside mmu notifier callback from
compactd or fork or numa balancing could release the last reference
of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
with below backtrace.

The deadlock will leak kfd process as mmu notifier release is not called
and cause VRAM leaking.

The fix is to take mm reference mmget_non_zero when adding prange to the
deferred list to pair with mmput in deferred list work.

If prange split and add into pchild list, the pchild work_item.mm is not
used, so remove the mm parameter from svm_range_unmap_split and
svm_range_add_child.

The backtrace of hung task:

 INFO: task python:348105 blocked for more than 64512 seconds.
 Call Trace:
  __schedule+0x1c3/0x550
  schedule+0x46/0xb0
  rwsem_down_write_slowpath+0x24b/0x4c0
  unlink_anon_vmas+0xb1/0x1c0
  free_pgtables+0xa9/0x130
  exit_mmap+0xbc/0x1a0
  mmput+0x5a/0x140
  svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
  mn_itree_invalidate+0x72/0xc0
  __mmu_notifier_invalidate_range_start+0x48/0x60
  try_to_unmap_one+0x10fa/0x1400
  rmap_walk_anon+0x196/0x460
  try_to_unmap+0xbb/0x210
  migrate_page_unmap+0x54d/0x7e0
  migrate_pages_batch+0x1c3/0xae0
  migrate_pages_sync+0x98/0x240
  migrate_pages+0x25c/0x520
  compact_zone+0x29d/0x590
  compact_zone_order+0xb6/0xf0
  try_to_compact_pages+0xbe/0x220
  __alloc_pages_direct_compact+0x96/0x1a0
  __alloc_pages_slowpath+0x410/0x930
  __alloc_pages_nodemask+0x3a9/0x3e0
  do_huge_pmd_anonymous_page+0xd7/0x3e0
  __handle_mm_fault+0x5e3/0x5f0
  handle_mm_fault+0xf7/0x2e0
  hmm_vma_fault.isra.0+0x4d/0xa0
  walk_pmd_range.isra.0+0xa8/0x310
  walk_pud_range+0x167/0x240
  walk_pgd_range+0x55/0x100
  __walk_page_range+0x87/0x90
  walk_page_range+0xf6/0x160
  hmm_range_fault+0x4f/0x90
  amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
  amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
  init_user_pages+0xb1/0x2a0 [amdgpu]
  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
  kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
  kfd_ioctl+0x29d/0x500 [amdgpu]

(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)


Remediation:
net: avoid race between device unregistration and ethnl ops
CVE: CVE-2025-21701
Component: kernel
CWE: CWE-362
Severity: Low
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-02-13T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: avoid race between device unregistration and ethnl ops

The following trace can be seen if a device is being unregistered while
its number of channels are being modified.

  DEBUG_LOCKS_WARN_ON(lock->magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   <TASK>
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.

Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.

Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the device reference is retrieved from within
the rtnl lock section there. Once dismantle started, the net device is
unlisted and no reference will be found.


Remediation:
nfsd: fix refcount leak in nfsd_set_fh_dentry()
CVE: CVE-2025-40212
Component: kernel
CWE: CWE-772
Severity: Moderate
CVSS v3: 5.2/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-24T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix refcount leak in nfsd_set_fh_dentry()

nfsd exports a "pseudo root filesystem" which is used by NFSv4 to find
the various exported filesystems using LOOKUP requests from a known root
filehandle.  NFSv3 uses the MOUNT protocol to find those exported
filesystems and so is not given access to the pseudo root filesystem.

If a v3 (or v2) client uses a filehandle from that filesystem,
nfsd_set_fh_dentry() will report an error, but still stores the export
in "struct svc_fh" even though it also drops the reference (exp_put()).
This means that when fh_put() is called an extra reference will be dropped
which can lead to use-after-free and possible denial of service.

Normal NFS usage will not provide a pseudo-root filehandle to a v3
client.  This bug can only be triggered by the client synthesising an
incorrect filehandle.

To fix this we move the assignments to the svc_fh later, after all
possible error cases have been detected.

Statement: A refcount imbalance in nfsd_set_fh_dentry() could lead to a use-after-free when processing a crafted NFS filehandle that references the NFSv4 pseudo-root from an NFSv3 request. A remote attacker able to send malformed filehandles to an NFS server could trigger a kernel crash (DoS).

Remediation:
arm64/fpsimd: Discard stale CPU state when handling SME traps
CVE: CVE-2025-38170
Component: kernel
CWE: CWE-99
Severity: Low
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-07-03T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: Discard stale CPU state when handling SME traps

The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state
incorrectly, and a race with preemption can result in a task having
TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SME traps enabled). This can result in warnings from
do_sme_acc() where SME traps are not expected while TIF_SME is set:

|        /* With TIF_SME userspace shouldn't generate any traps */
|        if (test_and_set_thread_flag(TIF_SME))
|                WARN_ON(1);

This is very similar to the SVE issue we fixed in commit:

  751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")

The race can occur when the SME trap handler is preempted before and
after manipulating the saved FPSIMD/SVE/SME state, starting and ending on
the same CPU, e.g.

| void do_sme_acc(unsigned long esr, struct pt_regs *regs)
| {
|         // Trap on CPU 0 with TIF_SME clear, SME traps enabled
|         // task->fpsimd_cpu is 0.
|         // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
|         ...
|
|         // Preempted; migrated from CPU 0 to CPU 1.
|         // TIF_FOREIGN_FPSTATE is set.
|
|         get_cpu_fpsimd_context();
|
|         /* With TIF_SME userspace shouldn't generate any traps */
|         if (test_and_set_thread_flag(TIF_SME))
|                 WARN_ON(1);
|
|         if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
|                 unsigned long vq_minus_one =
|                         sve_vq_from_vl(task_get_sme_vl(current)) - 1;
|                 sme_set_vq(vq_minus_one);
|
|                 fpsimd_bind_task_to_cpu();
|         }
|
|         put_cpu_fpsimd_context();
|
|         // Preempted; migrated from CPU 1 to CPU 0.
|         // task->fpsimd_cpu is still 0
|         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
|         // - Stale HW state is reused (with SME traps enabled)
|         // - TIF_FOREIGN_FPSTATE is cleared
|         // - A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.

Note: this was originallly posted as [1].

[ Rutland: rewrite commit message ]


Remediation:
Linux kernel: Denial of Service in io_uring/net due to incorrect buffer handling
CVE: CVE-2025-68294
Component: kernel
CWE: CWE-99
Severity: Moderate
CVSS v3: 6.7/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
Release date: 2025-12-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

io_uring/net: ensure vectored buffer node import is tied to notification

When support for vectored registered buffers was added, the import
itself is using 'req' rather than the notification io_kiocb, sr->notif.
For non-vectored imports, sr->notif is correctly used. This is important
as the lifetime of the two may be different. Use the correct io_kiocb
for the vectored buffer import.

Statement: A lifetime mismatch in io_uring's vectored registered buffer import ties the buffer to the wrong io_kiocb, potentially leading to use-after-free when the main request is freed before the associated notification. A local attacker able to use io_uring with vectored registered buffers may trigger memory corruption in kernel context. The issue is locally exploitable and may allow privilege escalation due to heap UAF in the networking zero-copy path.

Remediation:
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.