huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
Credential Leakage in Infinispan CLI
CVE: CVE-2025-5731
Component: infinispan
CWE: CWE-209
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Release date: 2025-06-26T21:24:21.857000+00:00

A flaw was found in Infinispan CLI. A sensitive password, decoded from a Base64-encoded Kubernetes secret, is processed in plaintext and included in a command string that may expose the data in an error message when a command is not found.

Statement: Red Hat JBoss Enterprise Application Platform are not affected by this vulnerability.

This flaw is rated as a Moderate vulnerability rather than an Important one because it requires specific conditions to be met for sensitive data exposure to occur. The password is only revealed if a user executes an invalid CLI command after including the decoded secret in the command string, which is a user-side misuse rather than a flaw in the core authentication or encryption logic of Infinispan. Additionally, the exposure is local to the terminal or logs and does not involve unauthorized remote access, privilege escalation, or systemic compromise.

Remediation:
Before applying this update, make sure all previously released errata relevant to your system have been applied.

For details on how to apply this update, refer to: https://access.redhat.com/articles/11258
Currently, no mitigation is available for this vulnerability.
GNU Binutils Linker out-of-bounds read
CVE: CVE-2025-11494
Component: binutils
CWE: CWE-125
Severity: Low
CVSS v3: 3.4/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-10-08T19:32:07.225000+00:00

An out of bounds read flaw has been discovered in the GNU Binutils package. The impacted function is _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally.

Statement: Red Hat rates this vulnerability as Low as a result of how the GNU Binutils are configured to be used in Red Hat products. When running with default configurations the affected program will have limited privileges and thus the availability impact of this flaw will be restricted.

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.
proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
CVE: CVE-2025-38653
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 5.0/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-08-22T00:00:00+00:00

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

proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al

Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. 
It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
proc_get_inode()").  Followed by AI Viro's suggestion, fix it in same
manner.

Statement: A race in procfs could dereference a freed proc_ops->proc_lseek pointer when a /proc file is opened while its backing module is being removed, leading to a kernel UAF and potential crash. The fix mirrors existing read/ioctl handling: it precomputes capability flags on entry creation and checks those flags (not the function pointer) in proc_reg_open(), eliminating the rmmod-time gap. This is primarily a local DoS: an unprivileged user can open/seek a proc entry while an administrator unloads the module.

Remediation:
zram: fix slot write race condition
CVE: CVE-2025-39941
Component: kernel
Severity: None
Release date: 2025-10-04T00:00:00+00:00

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

zram: fix slot write race condition

Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles.  Schematically we can have something like this:

CPU0                              CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
				zram_slot_lock()
				zs_free(handle)
				zram_slot_lock()

compress			compress
handle = zs_malloc()		handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
				zram_slot_lock
				zram_set_handle(handle)
				zram_slot_lock

Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early.  In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.


Remediation:
mailbox: zynqmp-ipi: Fix SGI cleanup on unbind
CVE: CVE-2025-40161
Component: kernel
Severity: None
Release date: 2025-11-12T00:00:00+00:00

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

mailbox: zynqmp-ipi: Fix SGI cleanup on unbind

The driver incorrectly determines SGI vs SPI interrupts by checking IRQ
number < 16, which fails with dynamic IRQ allocation. During unbind,
this causes improper SGI cleanup leading to kernel crash.

Add explicit irq_type field to pdata for reliable identification of SGI
interrupts (type-2) and only clean up SGI resources when appropriate.


Remediation:
net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device
CVE: CVE-2025-21921
Component: kernel
CWE: CWE-476
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-04-01T00:00:00+00:00

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

net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device

ethnl_req_get_phydev() is used to lookup a phy_device, in the case an
ethtool netlink command targets a specific phydev within a netdev's
topology.

It takes as a parameter a const struct nlattr *header that's used for
error handling :

       if (!phydev) {
               NL_SET_ERR_MSG_ATTR(extack, header,
                                   "no phy matching phyindex");
               return ERR_PTR(-ENODEV);
       }

In the notify path after a ->set operation however, there's no request
attributes available.

The typical callsite for the above function looks like:

	phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER],
				      info->extack);

So, when tb is NULL (such as in the ethnl notify path), we have a nice
crash.

It turns out that there's only the PLCA command that is in that case, as
the other phydev-specific commands don't have a notification.

This commit fixes the crash by passing the cmd index and the nlattr
array separately, allowing NULL-checking it directly inside the helper.


Remediation:
Keras deserialization of untrusted data
CVE: CVE-2025-49655
Component: keras
CWE: CWE-502
Severity: Important
CVSS v3: 8.4/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-10-17T15:20:27.308000+00:00

Deserialization of untrusted data can occur in versions of the Keras framework running versions 3.11.0 up to but not including 3.11.3, enabling a maliciously uploaded Keras file containing a TorchModuleWrapper class to run arbitrary code on an end user’s system when loaded despite safe mode being enabled. The vulnerability can be triggered through both local and remote files.

Statement: Red Hat products in their default configuration do not allow remote upload of model files.

Remediation:
For Red Hat OpenShift AI 2.25.1 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this errata update:

https://docs.redhat.com/en/documentation/red_hat_openshift_ai/
The Model Transparency CLI Image is a containerized command-line tool for signing and verifying AI/ML workloads against a private Red Hat Trusted Artifact Signer (RHTAS) instance. It lets teams create signatures and attestations for model artifacts and validate them at build or deploy time using enterprise trust material (e.g., Fulcio/Rekor).
For details on using the Model Transparency CLI image, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
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.
tcp: drop secpath at the same time as we currently drop dst
CVE: CVE-2025-21864
Component: kernel
CWE: CWE-476
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-03-12T00:00:00+00:00

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

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while
running tests that boil down to:
 - create a pair of netns
 - run a basic TCP test over ipcomp6
 - delete the pair of netns

The xfrm_state found on spi_byaddr was not deleted at the time we
delete the netns, because we still have a reference on it. This
lingering reference comes from a secpath (which holds a ref on the
xfrm_state), which is still attached to an skb. This skb is not
leaked, it ends up on sk_receive_queue and then gets defer-free'd by
skb_attempt_defer_free.

The problem happens when we defer freeing an skb (push it on one CPU's
defer_list), and don't flush that list before the netns is deleted. In
that case, we still have a reference on the xfrm_state that we don't
expect at this point.

We already drop the skb's dst in the TCP receive path when it's no
longer needed, so let's also drop the secpath. At this point,
tcp_filter has already called into the LSM hooks that may require the
secpath, so it should not be needed anymore. However, in some of those
places, the MPTCP extension has just been attached to the skb, so we
cannot simply drop all extensions.

Statement: The bug is that memory leak could happen. The security impact is limited, because no kernel panic or other errors that could be used for privileges escalation or other attack. For triggering the bug user have to use ipcomp6 and MPTCP extension.

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.
Tarfile extracts filtered members when errorlevel=0
CVE: CVE-2025-4435
Component: cpython
CWE: CWE-706
Severity: Moderate
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Release date: 2025-06-03T12:59:06.792000+00:00

A flaw was found in CPython's tarfile module. This vulnerability allows unauthorized file extraction via crafted tar archives when TarFile.errorlevel=0, bypassing expected filtering mechanisms.

Statement: The severity of this vulnerability was lowered due to the fact that successful exploitation requires the attacker to convince a privileged user or process to extract a malicious tar file. Since tar file extraction typically occurs in trusted contexts or with elevated privileges, the impact is reduced by the requirement of such access.

Versions of python36:3.6/python36 as shipped with Red Hat Enterprise Linux 8 are marked as 'Not affected' as they just provide "symlinks" to the main python3 component, which provides the actual interpreter of the Python programming language.

Remediation:
The containers required to run Discovery can be installed through discovery-installer RPM. See the official documentation for more details.
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.
CGI::Simple response splitting flaw
CVE: CVE-2025-40927
Component: perl-cgi-simple
CVSS v3: 7.3/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-08-29T00:10:07.161000+00:00

An HTTP response splitting flaw was found in the CGI::Simple Perl module. This flaw in CGI::Simple allows HTTP response header injection, which can be used for a reflected cross-site scripting (XSS) attack or an open redirect under certain conditions. Although some validation exists, it can be bypassed using URL-encoded values, allowing an attacker to inject untrusted content into the response via query parameters. As a result, an attacker can inject a line break, such as %0A, into the parameter value, causing the server to split the HTTP response and inject arbitrary headers, or an HTML/JavaScript body, leading to reflected cross-site scripting (XSS), open redirect, or other attacks.

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:
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.
vaultwarden allows escalation of privilege via variable confusion in OrgHeaders trait
CVE: CVE-2025-24365
Component: vaultwarden
CVSS v3: 8.3/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Release date: 2025-01-27T17:49:57.796000+00:00

vaultwarden is an unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. Attacker can obtain owner rights of other organization. Hacker should know the ID of victim organization (in real case the user can be a part of the organization as an unprivileged user) and be the owner/admin of other organization (by default you can create your own organization) in order to attack. This vulnerability is fixed in 1.33.0.

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:
thunderbird: Incorrect boundary conditions in the JavaScript: WebAssembly component
CVE: CVE-2025-13016
Component: firefox
CWE: CWE-787
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-11-11T15:47:14.370000+00:00

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue: Incorrect boundary conditions in the JavaScript: WebAssembly component.

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

Remediation:
ftrace: Fix UAF when lookup kallsym after ftrace disabled
CVE: CVE-2025-38346
Component: kernel
CWE: CWE-416
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-10T00:00:00+00:00

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

ftrace: Fix UAF when lookup kallsym after ftrace disabled

The following issue happens with a buggy module:

BUG: unable to handle page fault for address: ffffffffc05d0218
PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
RIP: 0010:sized_strscpy+0x81/0x2f0
RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000
RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d
RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68
R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038
R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff
FS:  00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ftrace_mod_get_kallsym+0x1ac/0x590
 update_iter_mod+0x239/0x5b0
 s_next+0x5b/0xa0
 seq_read_iter+0x8c9/0x1070
 seq_read+0x249/0x3b0
 proc_reg_read+0x1b0/0x280
 vfs_read+0x17f/0x920
 ksys_read+0xf3/0x1c0
 do_syscall_64+0x5f/0x2e0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The above issue may happen as follows:
(1) Add kprobe tracepoint;
(2) insmod test.ko;
(3)  Module triggers ftrace disabled;
(4) rmmod test.ko;
(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;
ftrace_mod_get_kallsym()
...
strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);
...

The problem is when a module triggers an issue with ftrace and
sets ftrace_disable. The ftrace_disable is set when an anomaly is
discovered and to prevent any more damage, ftrace stops all text
modification. The issue that happened was that the ftrace_disable stops
more than just the text modification.

When a module is loaded, its init functions can also be traced. Because
kallsyms deletes the init functions after a module has loaded, ftrace
saves them when the module is loaded and function tracing is enabled. This
allows the output of the function trace to show the init function names
instead of just their raw memory addresses.

When a module is removed, ftrace_release_mod() is called, and if
ftrace_disable is set, it just returns without doing anything more. The
problem here is that it leaves the mod_list still around and if kallsyms
is called, it will call into this code and access the module memory that
has already been freed as it will return:

  strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);

Where the "mod" no longer exists and triggers a UAF bug.


Remediation:
Trustee's attestation-policy endpoint missing autentication
CVE: CVE-2025-61779
Component: trustee
CWE: CWE-639
Severity: Important
CVSS v3: 8.6/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L
Release date: 2025-10-09T20:53:33.855000+00:00

Confidential Containers's Trustee project contains tools and components for attesting confidential guests and providing secrets to them. In versions prior to 0.15.0, the attestation-policy endpoint didn't check if the kbs-client submitting the request was actually authenticated (had the right key). This allowed any kbs-client to actually change the attestation policy. Version 0.15.0 fixes the issue.


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.
NULL Pointer Dereference in load() (bin_dyldcache.c) Leads to Denial of Service
CVE: CVE-2025-63744
Component: radare2
CVSS v3: 5.4/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-11-14T00:00:00+00:00

A NULL pointer dereference vulnerability was discovered in radare2 within the load() function of bin_dyldcache.c. Processing a crafted file can cause a segmentation fault and crash the program.

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:
vhost: Take a reference on the task in struct vhost_task
CVE: CVE-2025-40024
Component: kernel
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-10-24T00:00:00+00:00

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

vhost: Take a reference on the task in struct vhost_task.

vhost_task_create() creates a task and keeps a reference to its
task_struct. That task may exit early via a signal and its task_struct
will be released.
A pending vhost_task_wake() will then attempt to wake the task and
access a task_struct which is no longer there.

Acquire a reference on the task_struct while creating the thread and
release the reference while the struct vhost_task itself is removed.
If the task exits early due to a signal, then the vhost_task_wake() will
still access a valid task_struct. The wake is safe and will be skipped
in this case.

Statement: vhost_task stored a raw task_struct pointer without holding a reference. If the worker thread exited early, a later vhost_task_wake() could touch a freed task_struct, leading to a use-after-free and potential kernel crash or corruption. The fix grabs a reference with get_task_struct() at creation and drops it with put_task_struct() on teardown, ensuring the pointer remains valid even if the thread exits.

Remediation:
The issue can only be triggered by privileged processes that have access to /dev/vhost-* devices (typically QEMU/KVM or other virtualization backends). If Kvm or Qemu not being used, then regular user cannot trigger it.
Regular unprivileged users cannot reach this code path because vhost_task_create() is invoked only within the kernel when a vhost device is opened by a process with sufficient capabilities (e.g., root or CAP_NET_ADMIN).
Therefore, systems where unprivileged users have no access to /dev/vhost-* are not directly exploitable.
lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts
CVE: CVE-2025-39804
Component: kernel
Severity: None
Release date: 2025-09-15T00:00:00+00:00

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

lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts

Restore the SIMD usability check that was removed by commit a59e5468a921
("crypto: arm64/poly1305 - Add block-only interface").

This safety check is cheap and is well worth eliminating a footgun.
While the Poly1305 functions should not be called when SIMD registers
are unusable, if they are anyway, they should just do the right thing
instead of corrupting random tasks' registers and/or computing incorrect
MACs.  Fixing this is also needed for poly1305_kunit to pass.

Just use may_use_simd() instead of the original crypto_simd_usable(),
since poly1305_kunit won't rely on crypto_simd_disabled_for_test.


Remediation:
ksmbd: limit repeated connections from clients with the same IP
CVE: CVE-2025-38501
Component: kernel
Severity: None
Release date: 2025-08-16T00:00:00+00:00

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

ksmbd: limit repeated connections from clients with the same IP

Repeated connections from clients with the same IP address may exhaust
the max connections and prevent other normal client connections.
This patch limit repeated connections from clients with the same IP.


Remediation: