huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
CVE: CVE-2025-2769
Component: Bdrive NetDrive Uncontrolled Search Path Element Local Privilege Escalation Vulnerability
Release date: 2025-03-25T23:22:59.880000+00:00

Bdrive NetDrive Uncontrolled Search Path Element Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Bdrive NetDrive. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.

The specific flaw exists within the configuration of OpenSSL. The product loads an OpenSSL configuration file from an unsecured location. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-25295.

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:
OpenShift Service Mesh 2.6.3 and 2.5.6 Envoy Header Handling Allows Log Injection and Potential Spoofing
CVE: CVE-2025-0754
Component: envoyproxy
CWE: CWE-117
Severity: Moderate
CVSS v3: 4.5/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Release date: 2025-01-23T00:00:00+00:00

The vulnerability was found in OpenShift Service Mesh 2.6.3 and 2.5.6. This issue occurs due to improper sanitization of HTTP headers by Envoy, particularly the x-forwarded-for header. This lack of sanitization can allow attackers to inject malicious payloads into service mesh logs, leading to log injection and spoofing attacks. Such injections can mislead logging mechanisms, enabling attackers to manipulate log entries or execute reflected cross-site scripting (XSS) attacks.


Remediation:
virtio: break and reset virtio devices on device_shutdown()
CVE: CVE-2025-38064
Component: kernel
CWE: CWE-826
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-06-18T00:00:00+00:00

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

virtio: break and reset virtio devices on device_shutdown()

Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
accesses during the hang.

	Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
	Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
	...

It was traced down to virtio-console. Kexec works fine if virtio-console
is not in use.

The issue is that virtio-console continues to write to the MMIO even after
underlying virtio-pci device is reset.

Additionally, Eric noticed that IOMMUs are reset before devices, if
devices are not reset on shutdown they continue to poke at guest memory
and get errors from the IOMMU. Some devices get wedged then.

The problem can be solved by breaking all virtio devices on virtio
bus shutdown, then resetting them.


Remediation:
orangefs: fix xattr related buffer overflow..
CVE: CVE-2025-40306
Component: kernel
Severity: None
Release date: 2025-12-08T00:00:00+00:00

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

orangefs: fix xattr related buffer overflow...

Willy Tarreau <w@1wt.eu> forwarded me a message from
Disclosure <disclosure@aisle.com> with the following
warning:

> The helper `xattr_key()` uses the pointer variable in the loop condition
> rather than dereferencing it. As `key` is incremented, it remains non-NULL
> (until it runs into unmapped memory), so the loop does not terminate on
> valid C strings and will walk memory indefinitely, consuming CPU or hanging
> the thread.

I easily reproduced this with setfattr and getfattr, causing a kernel
oops, hung user processes and corrupted orangefs files. Disclosure
sent along a diff (not a patch) with a suggested fix, which I based
this patch on.

After xattr_key started working right, xfstest generic/069 exposed an
xattr related memory leak that lead to OOM. xattr_key returns
a hashed key.  When adding xattrs to the orangefs xattr cache, orangefs
used hash_add, a kernel hashing macro. hash_add also hashes the key using
hash_log which resulted in additions to the xattr cache going to the wrong
hash bucket. generic/069 tortures a single file and orangefs does a
getattr for the xattr "security.capability" every time. Orangefs
negative caches on xattrs which includes a kmalloc. Since adds to the
xattr cache were going to the wrong bucket, every getattr for
"security.capability" resulted in another kmalloc, none of which were
ever freed.

I changed the two uses of hash_add to hlist_add_head instead
and the memory leak ceased and generic/069 quit throwing furniture.


Remediation:
Bison Double Free Vulnerability
CVE: CVE-2025-8734
Component: bison
Release date: 2025-08-08T18:02:07.827000+00:00

This CVE has been marked as Rejected by the assigning CNA.

Statement: This CVE has been marked as Rejected by the assigning CNA.

Remediation:
Revert "riscv: Define TASK_SIZE_MAX for __access_ok()"
CVE: CVE-2025-38434
Component: kernel
Severity: None
Release date: 2025-07-25T00:00:00+00:00

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

Revert "riscv: Define TASK_SIZE_MAX for __access_ok()"

This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for
__access_ok()").

This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),
because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some
computation.

The reasoning was that all user addresses are less than LONG_MAX, and all
kernel addresses are greater than LONG_MAX. Therefore access_ok() can
filter kernel addresses.

Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but
access_ok() let them pass. That was thought to be okay, because they are
not valid addresses at hardware level.

Unfortunately, one case is missed: get_user_pages_fast() happily accepts
addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses
get_user_pages_fast(). This causes the problem reported by Robert [1].

Therefore, revert this commit. TASK_SIZE_MAX is changed to the default:
TASK_SIZE.

This unfortunately reduces performance, because TASK_SIZE is more expensive
to compute compared to LONG_MAX. But correctness first, we can think about
optimization later, if required.


Remediation:
Object corruption in V8
CVE: CVE-2025-0611
Component: chromium-browser
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H
Release date: 2025-01-22T19:22:36.353000+00:00

Object corruption in V8 in Google Chrome prior to 132.0.6834.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

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:
Timing Attack Vulnerability in SCRAM Authentication
CVE: CVE-2025-59432
Component: ongres-scram
CWE: CWE-385
Severity: Moderate
CVSS v3: 6.7/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Release date: 2025-09-22T19:22:37.117000+00:00

A timing attack vulnerability exists in the SCRAM Java implementation. The issue arises because Arrays.equals was used to compare secret values such as client proofs and server signatures. Since Arrays.equals performs a short-circuit comparison, the execution time varies depending on how many leading bytes match. This behavior could allow an attacker to perform a timing side-channel attack and potentially infer sensitive authentication material. All users relying on SCRAM authentication are impacted.


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
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
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.
wifi: iwlwifi: mld: avoid panic on init failure
CVE: CVE-2025-38121
Component: kernel
Severity: None
Release date: 2025-07-03T00:00:00+00:00

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

wifi: iwlwifi: mld: avoid panic on init failure

In case of an error during init, in_hw_restart will be set, but it will
never get cleared.
Instead, we will retry to init again, and then we will act like we are in a
restart when we are actually not.

This causes (among others) to a NULL pointer dereference when canceling
rx_omi::finished_work, that was not even initialized, because we thought
that we are in hw_restart.

Set in_hw_restart to true only if the fw is running, then we know that
FW was loaded successfully and we are not going to the retry loop.


Remediation:
Memory corruption when using JavaScript Text Segmentation
CVE: CVE-2025-0241
Component: firefox
CWE: CWE-119
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-01-07T16:07:06.824000+00:00

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: When segmenting specially crafted text, segmentation would corrupt memory leading to a potentially exploitable crash.

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

Remediation:
sunrpc: fix client side handling of tls alerts
CVE: CVE-2025-38571
Component: kernel
CWE: CWE-416
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-08-19T00:00:00+00:00

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

sunrpc: fix client side handling of tls alerts

A security exploit was discovered in NFS over TLS in tls_alert_recv
due to its assumption that there is valid data in the msghdr's
iterator's kvec.

Instead, this patch proposes the rework how control messages are
setup and used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and
process TLS data record types. As soon as it encounters a TLS control
message, it would return an error. At that point, NFS can setup a kvec
backed control buffer and read in the control message such as a TLS
alert. Scott found that a msg iterator can advance the kvec pointer
as a part of the copy process thus we need to revert the iterator
before calling into the tls_alert_recv.

Statement: A remotely reachable bug in the SUNRPC NFS-over-TLS client allowed a server to trigger a kernel crash by sending a TLS alert when the client assumed a valid control kvec in the message iterator. It requires NFS over TLS to be enabled on the client.
Exploitation is only possible in configurations where NFS over TLS is enabled, as the bug lies in the handling of TLS alert control messages in sunrpc. A remote attacker controlling an NFS/TLS session could send a crafted TLS alert to trigger a kernel crash on the client, leading to denial of service. However, since NFS over TLS is not enabled by default on most systems, the practical severity is lower unless explicitly deployed.

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.
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.
To mitigate this issue, prevent module sunrpc from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
CVE: CVE-2025-8671
Component: upstream
Release date: 2025-08-13T12:03:37.167000+00:00

A flaw was found in multiple implementations of HTTP/2 where malformed client requests can trigger server-side stream resets without triggering abuse counters. This issue, referred to as the "MadeYouReset" attack, allows malicious clients to induce excessive server workload by repeatedly causing server-side stream aborts. While not a protocol bug, this highlights a common implementation weakness that can be exploited to cause a denial of service (DoS).

Statement: This vulnerability is used to track additional modules, which may be vulnerable to the "MadeYouReset" attack. As Red Hat Product Security has not identified additional exposure, please reference these other vulnerabilities for detailed information: CVE-2025-48989, CVE-2025-55163, CVE-2025-5115, & CVE-2025-54500.

Remediation:
wifi: brcmfmac: Check the return value of of_property_read_string_index()
CVE: CVE-2025-21750
Component: kernel
CWE: CWE-20
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-02-27T00:00:00+00:00

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

wifi: brcmfmac: Check the return value of of_property_read_string_index()

Somewhen between 6.10 and 6.11 the driver started to crash on my
MacBookPro14,3. The property doesn't exist and 'tmp' remains
uninitialized, so we pass a random pointer to devm_kstrdup().

The crash I am getting looks like this:

BUG: unable to handle page fault for address: 00007f033c669379
PF: supervisor read access in kernel mode
PF: error_code(0x0001) - permissions violation
PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025
Oops: Oops: 0001 [#1] SMP PTI
CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1
Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024
RIP: 0010:strlen+0x4/0x30
Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202
RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001
RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379
RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a
R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8
R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30
FS:  00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ? __die+0x23/0x70
 ? page_fault_oops+0x149/0x4c0
 ? raw_spin_rq_lock_nested+0xe/0x20
 ? sched_balance_newidle+0x22b/0x3c0
 ? update_load_avg+0x78/0x770
 ? exc_page_fault+0x6f/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? __pfx_pci_conf1_write+0x10/0x10
 ? strlen+0x4/0x30
 devm_kstrdup+0x25/0x70
 brcmf_of_probe+0x273/0x350 [brcmfmac]


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.
ServiceAccount Token Exposure Leading to Token and Subject Access Reviews in OpenShift Tempo Operator
CVE: CVE-2025-2786
Component: tempo-operator
CWE: CWE-200
Severity: Moderate
CVSS v3: 4.5/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-03-25T00:00:00+00:00

A flaw was found in Tempo Operator, where it creates a ServiceAccount, ClusterRole, and ClusterRoleBinding when a user deploys a TempoStack or TempoMonolithic instance. This flaw allows a user with full access to their namespace to extract the ServiceAccount token and use it to submit TokenReview and SubjectAccessReview requests, potentially revealing information about other users' permissions. While this does not allow privilege escalation or impersonation, it exposes information that could aid in gathering information for further attacks.

Statement: Red Hat has evaluated this vulnerability and rated with a Moderate impact as the attacker is limited to read access and requires previous permissions to read the token and get access to the cluster metrics.

Remediation:
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/operators/administrator-tasks#olm-upgrading-operators
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/operators/administrator-tasks#olm-upgrading-operators
Currently, no mitigation is available for this vulnerability.
NULL pointer dereference in _gnutls_figure_common_ciphersuite()
CVE: CVE-2025-6395
Component: gnutls
CWE: CWE-476
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
Release date: 2025-07-10T07:56:53.029000+00:00

A NULL pointer dereference flaw was found in the GnuTLS software in _gnutls_figure_common_ciphersuite().


Remediation:
The container images provided by this update can be downloaded from the
Red Hat container registry at registry.redhat.io using the "podman pull" command.
The containers required to run Discovery can be installed through discovery-installer
RPM. See the official documentation for more details.
The Insights proxy container image provided here is downloaded by the Red Hat
Insights proxy product RPM.

Before applying this update, make sure all previously released errata relevant to
your system have been applied.
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.
xfig: Stack-overflow allows possible code execution via local input manipulation
CVE: CVE-2025-46397
Component: xfig
CWE: CWE-120
Severity: Moderate
CVSS v3: 7.9/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-04-23T20:55:09.795000+00:00

A flaw was found in xfig. This vulnerability allows possible code execution via local input manipulation via bezier_spline function.


Remediation:
nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
CVE: CVE-2025-38658
Component: kernel
Severity: None
Release date: 2025-08-22T00:00:00+00:00

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

nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails

Have nvmet_req_init() and req->execute() complete failed commands.

Description of the problem:
nvmet_req_init() calls __nvmet_req_complete() internally upon failure,
e.g., unsupported opcode, which calls the "queue_response" callback,
this results in nvmet_pci_epf_queue_response() being called, which will
call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is
different from DMA_TO_DEVICE. This results in a double completion as
nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()
when nvmet_req_init() fails.

Steps to reproduce:
On the host send a command with an unsupported opcode with nvme-cli,
For example the admin command "security receive"
$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096

This triggers a double completion as nvmet_req_init() fails and
nvmet_pci_epf_queue_response() is called, here iod->dma_dir is still
in the default state of "DMA_NONE" as set by default in
nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.
Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also
called in nvmet_pci_epf_exec_iod_work() leading to a double completion.
This not only sends two completions to the host but also corrupts the
state of the PCI NVMe target leading to kernel oops.

This patch lets nvmet_req_init() and req->execute() complete all failed
commands, and removes the double completion case in
nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where
double completions occurred.


Remediation:
.NET and Visual Studio Spoofing Vulnerability
CVE: CVE-2025-26646
Component: dotnet
CWE: CWE-290
Severity: Important
CVSS v3: 8.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-05-14T03:06:48.901000+00:00

A flaw was found in .NET and Visual Studio. This vulnerability allows an attacker to use specially crafted input to spoof trusted content or identities, potentially misleading users or systems. This issue requires user interaction and limited privileges but can lead to unauthorized actions or escalation due to incorrect identity or content validation handling.

Statement: This vulnerability in .NET is Important because it allows spoofing of trusted identities or content through crafted input, exploiting weaknesses in validation logic. While it requires user interaction and limited privileges, it can subvert authentication flows or integrity checks, leading to unauthorized actions. In security-sensitive contexts—like signed assembly loading, secure package feeds, or automated build systems—such spoofing can compromise trust boundaries and facilitate privilege escalation or supply chain attacks, making it more severe than a typical moderate flaw.

```

.NET 6.0 for RHEL-8, RHEL-9 and RHIVOS has reached its End of Life as of November 12, 2024, and is no longer supported. No fixes will be provided for this stream. For additional information about lifecycle for .NET on Red Hat Enterprise Linux, please refer to: https://access.redhat.com/support/policy/updates/net-core.

```

Remediation:
No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability.
KubeVirt VMI Denial-of-Service Using Pod Impersonation
CVE: CVE-2025-64435
Component: kubevirt.io/kubevirt
CWE: CWE-703
Severity: Moderate
CVSS v3: 5.4/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-07T22:57:02.600000+00:00

KubeVirt is a virtual machine management add-on for Kubernetes. Prior to 1.7.0-beta.0, a logic flaw in the virt-controller allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate virt-launcher pod associated with the VMI. This can mislead the virt-controller into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service). This vulnerability is fixed in 1.7.0-beta.0.


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.
MediaWiki: Cross-site Scripting via improper input neutralization
CVE: CVE-2025-61637
Component: MediaWiki
CVSS v3: 4.8/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in MediaWiki. A remote attacker with high privileges could exploit an Improper Neutralization of Input During Web Page Generation (Cross-site Scripting or XSS) vulnerability. This flaw allows the injection of malicious scripts into web pages, which can lead to information disclosure or session hijacking.

Statement: The vulnerability in MediaWiki allows for stored Cross-site Scripting (XSS) through system messages. Exploitation requires high privileges, limiting the attack surface to trusted administrators or users with elevated permissions. Red Hat products utilizing MediaWiki are affected if configured to allow untrusted content from highly privileged users.

Remediation: