huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
accel/ivpu: Fix locking order in ivpu_job_submit
CVE: CVE-2025-37907
Component: kernel
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-05-20T00:00:00+00:00

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

accel/ivpu: Fix locking order in ivpu_job_submit

Fix deadlock in job submission and abort handling.
When a thread aborts currently executing jobs due to a fault,
it first locks the global lock protecting submitted_jobs (#1).

After the last job is destroyed, it proceeds to release the related context
and locks file_priv (#2). Meanwhile, in the job submission thread,
the file_priv lock (#2) is taken first, and then the submitted_jobs
lock (#1) is obtained when a job is added to the submitted jobs list.

       CPU0                            CPU1
       ----                    	       ----
  (for example due to a fault)         (jobs submissions keep coming)

  lock(&vdev->submitted_jobs_lock) #1
  ivpu_jobs_abort_all()
  job_destroy()
                                      lock(&file_priv->lock)           #2
                                      lock(&vdev->submitted_jobs_lock) #1
  file_priv_release()
  lock(&vdev->context_list_lock)
  lock(&file_priv->lock)           #2

This order of locking causes a deadlock. To resolve this issue,
change the order of locking in ivpu_job_submit().

Statement: This patch fixes a potential deadlock in the Intel VPU driver caused by inconsistent mutex lock ordering during job submission and job abort paths. It is a correctness issue that may cause system stalls under heavy VPU job load or fault recovery.

Remediation:
usb: gadget: f_ecm: Refactor bind path to use __free()
CVE: CVE-2025-40093
Component: kernel
Severity: None
Release date: 2025-10-30T00:00:00+00:00

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

usb: gadget: f_ecm: Refactor bind path to use __free()

After an bind/unbind cycle, the ecm->notify_req is left stale. If a
subsequent bind fails, the unified error label attempts to free this
stale request, leading to a NULL pointer dereference when accessing
ep->ops->free_request.

Refactor the error handling in the bind path to use the __free()
automatic cleanup mechanism.


Remediation:
DML unspecified vulnerability (CPU Apr 2025)
CVE: CVE-2025-21580
Component: mysql
Severity: Moderate
CVSS v3: 5.9/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-04-15T20:30:55.550000+00:00

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


Remediation:
wifi: mt76: mt7996: add missing check for rx wcid entries
CVE: CVE-2025-39919
Component: kernel
Severity: None
Release date: 2025-10-01T00:00:00+00:00

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

wifi: mt76: mt7996: add missing check for rx wcid entries

Non-station wcid entries must not be passed to the rx functions.
In case of the global wcid entry, it could even lead to corruption in the wcid
array due to pointer being casted to struct mt7996_sta_link using container_of.


Remediation:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set()
CVE: CVE-2025-40139
Component: kernel
Severity: Moderate
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-12T00:00:00+00:00

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

smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().

smc_clc_prfx_set() is called during connect() and not under RCU
nor RTNL.

Using sk_dst_get(sk)->dev could trigger UAF.

Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()
after kernel_getsockname().

Note that the returned value of smc_clc_prfx_set() is not used
in the caller.

While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()
not to touch dst there.

Statement: The CLC prefix-selection code in SMC used sk_dst_get()->dev outside of any RCU protection, allowing dereferencing of a freed dst_entry during concurrent route changes. This creates a Use-After-Free condition inside the connect handshake.
A local process performing repeated connect() calls while routing structures are being updated or garbage-collected, causing dst to be freed concurrently.
Any local unprivileged user creating SMC-capable sockets can indirectly trigger the race.
For the CVSS the PR:L because only local processes can trigger this code path.
Exploitation requires race timing.

Remediation:
Missing unregister call for normal_exit command may lead to use-after-free
CVE: CVE-2025-61664
Component: grub2
CWE: CWE-825
Severity: Moderate
CVSS v3: 4.8/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-11-18T00:00:00+00:00

A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.

Statement: This vulnerability has been rated as have the impact of Moderate by the Red Hat Product Security team. This decision was made based in the fact an attacker needs local or physical access to the machine, to execute the normal_exit command after it was unloaded. Additionally the most likely outcome from an successful attack is a Denial of Crash by leading the grub2 to crash.

Remediation:
There is no known mitigation available for this vulnerability.
CVE: CVE-2025-7304
Component: IrfanView CADImage Plugin DWG File Parsing Memory Corruption Remote Code Execution Vulnerability
Release date: 2025-07-08T19:59:27.483000+00:00

IrfanView CADImage Plugin DWG File Parsing Memory Corruption Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of IrfanView CADImage Plugin. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of DWG files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26385.

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:
Linux kernel: Denial of Service due to race condition in fbcon setup
CVE: CVE-2025-68296
Component: kernel
CWE: CWE-367
Severity: Moderate
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-12-16T00:00:00+00:00

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

drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup

Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB
access in fbcon_remap_all(). Without holding the console lock the call
races with switching outputs.

VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon
function uses struct fb_info.node, which is set by register_framebuffer().
As the fb-helper code currently sets up VGA switcheroo before registering
the framebuffer, the value of node is -1 and therefore not a legal value.
For example, fbcon uses the value within set_con2fb_map() [1] as an index
into an array.

Moving vga_switcheroo_client_fb_set() after register_framebuffer() can
result in VGA switching that does not switch fbcon correctly.

Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),
which already holds the console lock. Fbdev calls fbcon_fb_registered()
from within register_framebuffer(). Serializes the helper with VGA
switcheroo's call to fbcon_remap_all().

Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info
as parameter, it really only needs the contained fbcon state. Moving the
call to fbcon initialization is therefore cleaner than before. Only amdgpu,
i915, nouveau and radeon support vga_switcheroo. For all other drivers,
this change does nothing.


Remediation:
github.com/containernetworking/plugins/plugins/meta/portmap: CNI portmap plugin: HostPort forwarding vulnerability allows traffic interception
CVE: CVE-2025-67499
Component: CNI portmap plugin
CWE: CWE-200
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-09T23:13:22.398000+00:00

A flaw was found in the CNI (Container Network Interface) portmap plugin. This vulnerability allows containers to intercept all traffic destined for a host port via inadvertent forwarding of traffic with the same destination port when the plugin is configured with the nftables backend, ignoring the destination IP.

Statement: This vulnerability is rated Moderate for Red Hat because it allows containers to intercept non-local traffic when the CNI portmap plugin is explicitly configured to use the `nftables` backend. This issue affects CNI portmap plugin versions 1.6.0 through 1.8.0. Red Hat products are only affected if the `nftables` backend is specifically enabled for the CNI portmap plugin.

Remediation:
Configure the CNI portmap plugin to use the `iptables` backend instead of `nftables`. This can typically be achieved by modifying the CNI network configuration. After making this configuration change, services utilizing the CNI portmap plugin may require a restart or reload for the changes to take effect.
Inappropriate implementation in V8
CVE: CVE-2025-12433
Component: chromium-browser
CVSS v3: 8.7/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-11-10T20:00:15.801000+00:00

Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)

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

Remediation:
ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered
CVE: CVE-2025-39763
Component: kernel
CWE: CWE-544
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-09-11T00:00:00+00:00

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

ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered

If a synchronous error is detected as a result of user-space process
triggering a 2-bit uncorrected error, the CPU will take a synchronous
error exception such as Synchronous External Abort (SEA) on Arm64. The
kernel will queue a memory_failure() work which poisons the related
page, unmaps the page, and then sends a SIGBUS to the process, so that
a system wide panic can be avoided.

However, no memory_failure() work will be queued when abnormal
synchronous errors occur. These errors can include situations like
invalid PA, unexpected severity, no memory failure config support,
invalid GUID section, etc. In such a case, the user-space process will
trigger SEA again.  This loop can potentially exceed the platform
firmware threshold or even trigger a kernel hard lockup, leading to a
system reboot.

Fix it by performing a force kill if no memory_failure() work is queued
for synchronous errors.

[ rjw: Changelog edits ]


Remediation:
CVE: CVE-2025-6796
Component: Marvell QConvergeConsole getAppFileBytes Directory Traversal Information Disclosure Vulnerability
Release date: 2025-06-27T22:57:58.349000+00:00

Marvell QConvergeConsole getAppFileBytes Directory Traversal Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Marvell QConvergeConsole. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the getAppFileBytes method. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to disclose information in the context of SYSTEM. Was ZDI-CAN-24916.

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:
sched/ext: Prevent update_locked_rq() calls with NULL rq
CVE: CVE-2025-38522
Component: kernel
Severity: None
Release date: 2025-08-16T00:00:00+00:00

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

sched/ext: Prevent update_locked_rq() calls with NULL rq

Avoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL
in the SCX_CALL_OP and SCX_CALL_OP_RET macros.

Previously, calling update_locked_rq(NULL) with preemption enabled could
trigger the following warning:

    BUG: using __this_cpu_write() in preemptible [00000000]

This happens because __this_cpu_write() is unsafe to use in preemptible
context.

rq is NULL when an ops invoked from an unlocked context. In such cases, we
don't need to store any rq, since the value should already be NULL
(unlocked). Ensure that update_locked_rq() is only called when rq is
non-NULL, preventing calling __this_cpu_write() on preemptible context.


Remediation:
Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"
CVE: CVE-2025-40210
Component: kernel
CWE: CWE-770
Severity: Moderate
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-21T00:00:00+00:00

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

Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"

I've found that pynfs COMP6 now leaves the connection or lease in a
strange state, which causes CLOSE9 to hang indefinitely. I've dug
into it a little, but I haven't been able to root-cause it yet.
However, I bisected to commit 48aab1606fa8 ("NFSD: Remove the cap on
number of operations per NFSv4 COMPOUND").

Tianshuo Han also reports a potential vulnerability when decoding
an NFSv4 COMPOUND. An attacker can place an arbitrarily large op
count in the COMPOUND header, which results in:

[   51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total
pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO),
nodemask=(null),cpuset=/,mems_allowed=0

when NFSD attempts to allocate the COMPOUND op array.

Let's restore the operation-per-COMPOUND limit, but increased to 200
for now.

Statement: The revert restores a limit on the number of NFSv4 COMPOUND operations to prevent unbounded memory allocation.
Without this limit, a crafted request with a huge op count could trigger vmalloc overflow and could crash the kernel remotely.

Remediation:
To mitigate this issue, prevent module nfsd from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()
CVE: CVE-2025-21703
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 7.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-02-18T00:00:00+00:00

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

netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()

qdisc_tree_reduce_backlog() notifies parent qdisc only if child
qdisc becomes empty, therefore we need to reduce the backlog of the
child qdisc before calling it. Otherwise it would miss the opportunity
to call cops->qlen_notify(), in the case of DRR, it resulted in UAF
since DRR uses ->qlen_notify() to maintain its active list.

Statement: The bug happens only if emulate network delay, loss, and packet re-ordering qdisc scheduler being used. By default it is disabled. It is hard to trigger it and the security impact is limited.

Remediation:
To mitigate this issue, prevent module sch_netem from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
Linux kernel erofs: Use-After-Free due to device type mismatch
CVE: CVE-2025-38172
Component: kernel
CWE: CWE-390
Severity: Moderate
CVSS v3: 7.5/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Release date: 2025-07-03T00:00:00+00:00

A flaw was found in the Linux kernel's erofs filesystem. A local attacker could exploit a use-after-free (UAF) vulnerability by mounting an erofs filesystem with a specific configuration where the primary and extra devices have mismatched types. This improper handling of device initialization errors could lead to a system crash (denial of service) or potentially allow a local attacker to execute arbitrary code, thereby gaining full control over the affected system.


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.
Linux kernel: Denial of Service in SMB client due to use-after-free in asynchronous crypto handling
CVE: CVE-2025-38488
Component: kernel
CWE: CWE-825
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-28T00:00:00+00:00

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

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from
crypt_message(), assuming all crypto operations are synchronous.
However, when hardware crypto accelerators are used, this can cause
use-after-free crashes:

  crypt_message()
    // Allocate the creq buffer containing the req
    creq = smb2_get_aead_req(..., &req);

    // Async encryption returns -EINPROGRESS immediately
    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

    // Free creq while async operation is still in progress
    kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for
performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,
the operation completes asynchronously. Without crypto_wait_req(),
the function immediately frees the request buffer, leading to crashes
when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto
driver later accesses the freed request structure, leading to kernel
crashes with NULL pointer dereferences.

The issue occurs because crypto_alloc_aead() with mask=0 doesn't
guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in
the mask, async implementations can be selected.

Fix by restoring the async crypto handling:
- DECLARE_CRYPTO_WAIT(wait) for completion tracking
- aead_request_set_callback() for async completion notification
- crypto_wait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation
completes, whether synchronous or asynchronous, while preserving the
CVE-2024-50047 fix.


Remediation:
sysfs: check visibility before changing group attribute ownership
CVE: CVE-2025-40355
Component: kernel
Severity: Low
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-12-16T00:00:00+00:00

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

sysfs: check visibility before changing group attribute ownership

Since commit 0c17270f9b92 ("net: sysfs: Implement is_visible for
phys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() can
hit WARN_ON() when trying to change owner of a file that isn't visible.
See the trace below:

 WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30
 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full)  4b783b4a638669fb644857f484487d17cb45ed1f
 Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025
 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30
 [...]
 Call Trace:
  <TASK>
  ? if6_seq_show+0x30/0x50
  do_setlink.isra.0+0xc7/0x1270
  ? __nla_validate_parse+0x5c/0xcc0
  ? security_capable+0x94/0x1a0
  rtnl_newlink+0x858/0xc20
  ? update_curr+0x8e/0x1c0
  ? update_entity_lag+0x71/0x80
  ? sched_balance_newidle+0x358/0x450
  ? psi_task_switch+0x113/0x2a0
  ? __pfx_rtnl_newlink+0x10/0x10
  rtnetlink_rcv_msg+0x346/0x3e0
  ? sched_clock+0x10/0x30
  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
  netlink_rcv_skb+0x59/0x110
  netlink_unicast+0x285/0x3c0
  ? __alloc_skb+0xdb/0x1a0
  netlink_sendmsg+0x20d/0x430
  ____sys_sendmsg+0x39f/0x3d0
  ? import_iovec+0x2f/0x40
  ___sys_sendmsg+0x99/0xe0
  __sys_sendmsg+0x8a/0xf0
  do_syscall_64+0x81/0x970
  ? __sys_bind+0xe3/0x110
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? sock_alloc_file+0x63/0xc0
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? alloc_fd+0x12e/0x190
  ? put_unused_fd+0x2a/0x70
  ? do_sys_openat2+0xa2/0xe0
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? exc_page_fault+0x7e/0x1a0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 [...]
  </TASK>

Fix this by checking is_visible() before trying to touch the attribute.


Remediation:
afs: Fix the maximum cell name length
CVE: CVE-2025-21646
Component: kernel
CWE: CWE-20
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-01-19T00:00:00+00:00

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

afs: Fix the maximum cell name length

The kafs filesystem limits the maximum length of a cell to 256 bytes, but a
problem occurs if someone actually does that: kafs tries to create a
directory under /proc/net/afs/ with the name of the cell, but that fails
with a warning:

        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405

because procfs limits the maximum filename length to 255.

However, the DNS limits the maximum lookup length and, by extension, the
maximum cell name, to 255 less two (length count and trailing NUL).

Fix this by limiting the maximum acceptable cellname length to 253.  This
also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.

Further, split the YFS VL record cell name maximum to be the 256 allowed by
the protocol and ignore the record retrieved by YFSVL.GetCellName if it
exceeds 253.


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.
drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling
CVE: CVE-2025-38467
Component: kernel
Severity: None
Release date: 2025-07-25T00:00:00+00:00

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

drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling

If there's support for another console device (such as a TTY serial),
the kernel occasionally panics during boot. The panic message and a
relevant snippet of the call stack is as follows:

  Unable to handle kernel NULL pointer dereference at virtual address 000000000000000
  Call trace:
    drm_crtc_handle_vblank+0x10/0x30 (P)
    decon_irq_handler+0x88/0xb4
    [...]

Otherwise, the panics don't happen. This indicates that it's some sort
of race condition.

Add a check to validate if the drm device can handle vblanks before
calling drm_crtc_handle_vblank() to avoid this.


Remediation: