huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
xsk: Harden userspace-supplied xdp_desc validation
CVE: CVE-2025-40159
Component: kernel
CWE: CWE-190
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-11-12T00:00:00+00:00

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

xsk: Harden userspace-supplied xdp_desc validation

Turned out certain clearly invalid values passed in xdp_desc from
userspace can pass xp_{,un}aligned_validate_desc() and then lead
to UBs or just invalid frames to be queued for xmit.

desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len
can cause positive integer overflow and wraparound, the same way low
enough desc->addr with a non-zero pool->tx_metadata_len can cause
negative integer overflow. Both scenarios can then pass the
validation successfully.
This doesn't happen with valid XSk applications, but can be used
to perform attacks.

Always promote desc->len to ``u64`` first to exclude positive
overflows of it. Use explicit check_{add,sub}_overflow() when
validating desc->addr (which is ``u64`` already).

bloat-o-meter reports a little growth of the code size:

add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)
Function                                     old     new   delta
xskq_cons_peek_desc                          299     330     +31
xsk_tx_peek_release_desc_batch               973    1002     +29
xsk_generic_xmit                            3148    3132     -16

but hopefully this doesn't hurt the performance much.

Statement: AF_XDP allows userspace to submit packet descriptors for zero-copy transmission. The validation functions check that descriptor addresses and lengths are within pool boundaries. When tx_metadata_len is non-zero, calculations add it to desc->len or subtract it from desc->addr. Since desc->len is u32, values near U32_MAX can wrap around when metadata is added, making invalid large sizes appear valid. Similarly, low desc->addr values can underflow during subtraction, passing validation incorrectly. While legitimate XDP applications don't send such values, attackers can exploit these overflows. The fix promotes desc->len to u64 before arithmetic and uses explicit overflow checking for desc->addr calculations.

Remediation:
usb: typec: altmodes/displayport: do not index invalid pin_assignments
CVE: CVE-2025-38391
Component: kernel
CWE: CWE-125
Severity: Moderate
CVSS v3: 5.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Release date: 2025-07-25T00:00:00+00:00

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

usb: typec: altmodes/displayport: do not index invalid pin_assignments

A poorly implemented DisplayPort Alt Mode port partner can indicate
that its pin assignment capabilities are greater than the maximum
value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
will cause a BRK exception due to an out of bounds array access.

Prevent for loop in pin_assignment_show from accessing
invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop
condition.

Statement: This patch addresses a potential out-of-bounds array access in the DisplayPort Alt Mode driver for USB Type-C.
If a connected device advertises invalid pin assignments beyond the supported DP_PIN_ASSIGN_F, the kernel function pin_assignment_show() may access memory outside the valid range, leading to a BRK exception or kernel crash.
The patch introduces a maximum pin assignment limit to prevent this.

The vulnerability is externally triggerable via a malicious or misbehaving USB-C device and may lead to denial-of-service or minor information disclosure through out-of-bounds reads.

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.
drm/xe/vf: Don't try to trigger a full GT reset if VF
CVE: CVE-2025-23162
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-05-01T00:00:00+00:00

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

drm/xe/vf: Don't try to trigger a full GT reset if VF

VFs don't have access to the GDRST(0x941c) register that driver
uses to reset a GT. Attempt to trigger a reset using debugfs:

 $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset

or due to a hang condition detected by the driver leads to:

 [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]
 [ ] xe 0000:00:02.1: [drm] GT0: reset queued
 [ ] xe 0000:00:02.1: [drm] GT0: reset started
 [ ] ------------[ cut here ]------------
 [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0
 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ] Call Trace:
 [ ]  <TASK>
 [ ]  ? show_regs+0x6c/0x80
 [ ]  ? __warn+0x93/0x1c0
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? report_bug+0x182/0x1b0
 [ ]  ? handle_bug+0x6e/0xb0
 [ ]  ? exc_invalid_op+0x18/0x80
 [ ]  ? asm_exc_invalid_op+0x1b/0x20
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]
 [ ]  ? __mutex_unlock_slowpath+0x41/0x2e0
 [ ]  xe_mmio_write32+0x64/0x150 [xe]
 [ ]  do_gt_reset+0x2f/0xa0 [xe]
 [ ]  gt_reset_worker+0x14e/0x1e0 [xe]
 [ ]  process_one_work+0x21c/0x740
 [ ]  worker_thread+0x1db/0x3c0

Fix that by sending H2G VF_RESET(0x5507) action instead.


Remediation:
Integer Overflow in llama.cpp
CVE: CVE-2025-53630
Component: llama.cpp
CVSS v3: 8.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-07-10T19:32:45.296000+00:00

An integer overflow flaw was found in llama.cpp. This flaw exists in the `gguf_init_from_file_impl` function in `ggml/src/gguf.cpp` and can lead to heap out-of-bounds read/write.

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:
CVE: CVE-2025-2023
Component: Ashlar-Vellum Cobalt LI File Parsing Integer Overflow Remote Code Execution Vulnerability
Release date: 2025-03-10T22:01:31.399000+00:00

Ashlar-Vellum Cobalt LI File Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ashlar-Vellum Cobalt. 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 LI files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25348.

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:
Regular Expression Denial of Service (ReDoS) in huggingface/transformers
CVE: CVE-2025-3262
Component: transformers
CWE: CWE-1333
Severity: Moderate
CVSS v3: 5.3/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-07-07T09:54:39.079000+00:00

A Regular Expression Denial of Service (ReDoS) vulnerability has been discovered in the Hugging Face Transformers library. This issue can be exploited by an attacker who is able to supply specially crafted malicious input. Such input can cause excessive processing time and resource consumption, leading to a denial of service condition in applications that integrate the Transformers package.


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.
fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()
CVE: CVE-2025-37988
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-05-20T00:00:00+00:00

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

fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()

Normally do_lock_mount(path, _) is locking a mountpoint pinned by
*path and at the time when matching unlock_mount() unlocks that
location it is still pinned by the same thing.

Unfortunately, for 'beneath' case it's no longer that simple -
the object being locked is not the one *path points to.  It's the
mountpoint of path->mnt.  The thing is, without sufficient locking
->mnt_parent may change under us and none of the locks are held
at that point.  The rules are
	* mount_lock stabilizes m->mnt_parent for any mount m.
	* namespace_sem stabilizes m->mnt_parent, provided that
m is mounted.
	* if either of the above holds and refcount of m is positive,
we are guaranteed the same for refcount of m->mnt_parent.

namespace_sem nests inside inode_lock(), so do_lock_mount() has
to take inode_lock() before grabbing namespace_sem.  It does
recheck that path->mnt is still mounted in the same place after
getting namespace_sem, and it does take care to pin the dentry.
It is needed, since otherwise we might end up with racing mount --move
(or umount) happening while we were getting locks; in that case
dentry would no longer be a mountpoint and could've been evicted
on memory pressure along with its inode - not something you want
when grabbing lock on that inode.

However, pinning a dentry is not enough - the matching mount is
also pinned only by the fact that path->mnt is mounted on top it
and at that point we are not holding any locks whatsoever, so
the same kind of races could end up with all references to
that mount gone just as we are about to enter inode_lock().
If that happens, we are left with filesystem being shut down while
we are holding a dentry reference on it; results are not pretty.

What we need to do is grab both dentry and mount at the same time;
that makes inode_lock() safe *and* avoids the problem with fs getting
shut down under us.  After taking namespace_sem we verify that
path->mnt is still mounted (which stabilizes its ->mnt_parent) and
check that it's still mounted at the same place.  From that point
on to the matching namespace_unlock() we are guaranteed that
mount/dentry pair we'd grabbed are also pinned by being the mountpoint
of path->mnt, so we can quietly drop both the dentry reference (as
the current code does) and mnt one - it's OK to do under namespace_sem,
since we are not dropping the final refs.

That solves the problem on do_lock_mount() side; unlock_mount()
also has one, since dentry is guaranteed to stay pinned only until
the namespace_unlock().  That's easy to fix - just have inode_unlock()
done earlier, while it's still pinned by mp->m_dentry.


Remediation:
thunderbird: Content-Disposition header ignored when a file is included in an embed or object tag
CVE: CVE-2025-6430
Component: firefox
CWE: CWE-79
Severity: Moderate
CVSS v3: 6.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Release date: 2025-06-24T12:28:01.020000+00:00

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue: When a file download is specified via the Content-Disposition header, that directive would be ignored if the file was included via a <embed> or <object> tag, potentially making a website vulnerable to a cross-site scripting attack.

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

Remediation:
riscv: uprobes: Add missing fence.i after building the XOL buffer
CVE: CVE-2025-37822
Component: kernel
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-05-08T00:00:00+00:00

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

riscv: uprobes: Add missing fence.i after building the XOL buffer

The XOL (execute out-of-line) buffer is used to single-step the
replaced instruction(s) for uprobes. The RISC-V port was missing a
proper fence.i (i$ flushing) after constructing the XOL buffer, which
can result in incorrect execution of stale/broken instructions.

This was found running the BPF selftests "test_progs:
uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the
uprobes tests randomly blew up.


Remediation:
XGrammar affected by Denial of Service by infinite recursion grammars
CVE: CVE-2025-57809
Component: xgrammar
CWE: CWE-674
Severity: Important
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-08-25T21:22:00.226000+00:00

A flaw was found in xgrammar. Recursive grammar definitions could trigger infinite recursion during parsing in GrammarMatcherBase::ExpandEquivalentStackElements, leading to unbounded stack growth and a segmentation fault. This vulnerability allows remote attackers to cause a denial of service (DoS) when untrusted grammar is processed.

Statement: This vulnerability is considered Important because it can be exploited remotely, without authentication or user interaction, and directly impacts the availability of systems that rely on xgrammar for structured output parsing. Unlike a Moderate flaw that might require unusual conditions or only cause partial degradation, the infinite recursion issue reliably leads to process termination or complete resource exhaustion when malicious input is supplied. Since xgrammar is often integrated into long-running LLM inference services or API backends, a single crafted grammar can consistently force these services into a denial-of-service state, making it a practical, high-impact attack vector. While it does not compromise confidentiality or integrity, the ease of exploitation, network accessibility, and total loss of availability elevate it from a moderate to an important security issue.

Remediation:
For more information visit https://access.redhat.com/errata/RHSA-2025:19427
For more information visit https://access.redhat.com/errata/RHSA-2025:19429
For more information visit https://access.redhat.com/errata/RHSA-2025:19424
For more information visit https://access.redhat.com/errata/RHSA-2025:19430
For more information visit https://access.redhat.com/errata/RHSA-2025:19426
For more information visit https://access.redhat.com/errata/RHSA-2025:19422
For more information visit https://access.redhat.com/errata/RHSA-2025:19428
For more information visit https://access.redhat.com/errata/RHSA-2025:19425
For more information visit https://access.redhat.com/errata/RHSA-2025:19421
For more information visit https://access.redhat.com/errata/RHSA-2025:19423
Mitigation is either unavailable or does not meet Red Hat Product Security standards for usability, deployment, applicability, or stability.
drm/amdgpu: validate userq input args
CVE: CVE-2025-40335
Component: kernel
Severity: None
Release date: 2025-12-09T00:00:00+00:00

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

drm/amdgpu: validate userq input args

This will help on validating the userq input args, and
rejecting for the invalid userq request at the IOCTLs
first place.


Remediation:
espintcp: fix skb leaks
CVE: CVE-2025-38057
Component: kernel
CWE: CWE-772
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-06-18T00:00:00+00:00

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

espintcp: fix skb leaks

A few error paths are missing a kfree_skb.


Remediation:
ALSA: ac97: fix a double free in snd_ac97_controller_register()
CVE: CVE-2025-71192
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

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

ALSA: ac97: fix a double free in snd_ac97_controller_register()

If ac97_add_adapter() fails, put_device() is the correct way to drop
the device reference. kfree() is not required.
Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do
the cleanup.

Found by code review.


Remediation:
NULL Pointer Dereference on libsoup through  function "sniff_mp4" in soup-content-sniffer.c
CVE: CVE-2025-32909
Component: libsoup
CWE: CWE-476
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-04-14T00:00:00+00:00

A flaw was found in libsoup. SoupContentSniffer may be vulnerable to a NULL pointer dereference in the sniff_mp4 function. The HTTP server may cause the libsoup client to crash.

Statement: This vulnerability is currently considered Moderate as this may only affect the client HTTP side.

Remediation:
Currently, no mitigation is available for this vulnerability.
Incorrect Privilege Assignment
CVE: CVE-2025-4374
Component: quay
CWE: CWE-266
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Release date: 2025-05-06T00:00:00+00:00

A flaw was found in Quay. When an organization acts as a proxy cache, and a user or robot pulls an image that hasn't been mirrored yet, they are granted "Admin" permissions on the newly created repository.


Remediation:
Permissions can be updated after creation but there's no preventative measure before hand.
cifs: fix memory leak in smb3_fs_context_parse_param error path
CVE: CVE-2025-68219
Component: kernel
CWE: CWE-772
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:

cifs: fix memory leak in smb3_fs_context_parse_param error path

Add proper cleanup of ctx->source and fc->source to the
cifs_parse_mount_err error handler. This ensures that memory allocated
for the source strings is correctly freed on all error paths, matching
the cleanup already performed in the success path by
smb3_cleanup_fs_context_contents().
Pointers are also set to NULL after freeing to prevent potential
double-free issues.

This change fixes a memory leak originally detected by syzbot. The
leak occurred when processing Opt_source mount options if an error
happened after ctx->source and fc->source were successfully
allocated but before the function completed.

The specific leak sequence was:
1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory
2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory
3. A subsequent error jumps to cifs_parse_mount_err
4. The old error handler freed passwords but not the source strings,
causing the memory to leak.

This issue was not addressed by commit e8c73eb7db0a ("cifs: client:
fix memory leak in smb3_fs_context_parse_param"), which only fixed
leaks from repeated fsconfig() calls but not this error path.

Patch updated with minor change suggested by kernel test robot


Remediation:
GNU Binutils ld elflink.c _bfd_elf_gc_mark_rsec heap-based overflow
CVE: CVE-2025-1176
Component: binutils
CWE: CWE-787
Severity: Moderate
CVSS v3: 5.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L
Release date: 2025-02-11T05:31:08.015000+00:00

A flaw was found in GNU Binutils. This vulnerability allows a heap-based buffer overflow via the _bfd_elf_gc_mark_rsec function.


Remediation:
minio-java Client XML Tag is Vulnerable to Value Substitution
CVE: CVE-2025-59952
Component: io.minio/minio
CWE: CWE-611
Severity: Important
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Release date: 2025-09-29T23:32:33.994000+00:00

In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. Attackers could craft malicious XML inputs to extract sensitive data from the system's properties or environment variables, potentially compromising security in applications relying on minio-java for object storage operations.


Remediation:
Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on.
The References section of this erratum contains a download link (you must log in to download the update).
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.
assertion failure in run_jq_tests() of the file jq_test.c
CVE: CVE-2025-9403
Component: jq
CWE: CWE-617
Severity: Low
CVSS v3: 3.2/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Release date: 2025-08-25T02:02:07.038000+00:00

A vulnerability has been identified in the jq JSON processor where malformed JSON input containing invalid Unicode escape sequences can trigger an assertion failure in the test suite’s parsing consistency checks. This flaw arises from inconsistencies between expected and reparsed JSON values during serialization and deserialization, potentially allowing an attacker to exploit the issue by supplying specially crafted JSON data to cause abnormal termination or denial of service during test execution, highlighting weaknesses in jq’s parsing reliability.

Statement: This vulnerability is limited to jq’s internal test framework and does not affect jq’s core functionality in production use. Exploitation requires supplying malformed JSON with invalid Unicode escape sequences during test execution, which can trigger an assertion failure and abnormal termination of the test suite. The issue is rated Low severity as it only causes test crashes in debug or development environments, without exposing sensitive data, compromising system integrity, or affecting jq’s normal JSON processing in production.

Remediation:
No action is required for production users, as the vulnerability only affects jq’s internal test framework and does not impact its core JSON processing functionality. Standard deployments of jq remain unaffected. Developers and testers are advised to avoid running the test suite with untrusted or malformed JSON input until a fix is applied.
Linux kernel: Denial of Service via device refcount leak in Appletalk protocol implementation
CVE: CVE-2025-38542
Component: kernel
CWE: CWE-911
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-08-16T00:00:00+00:00

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

net: appletalk: Fix device refcount leak in atrtr_create()

When updating an existing route entry in atrtr_create(), the old device
reference was not being released before assigning the new device,
leading to a device refcount leak. Fix this by calling dev_put() to
release the old device reference before holding the new one.


Remediation:
To mitigate this issue on affected Red Hat Enterprise Linux 6 ELS systems, and as a general hardening measure on other systems where Appletalk is not required, prevent the `appletalk` kernel module from loading. This can be achieved by creating a modprobe configuration file.

Create a file named `/etc/modprobe.d/disable-appletalk.conf` with the following content:
```
install appletalk /bin/true
blacklist appletalk
```
After creating the file, regenerate the initramfs and reboot the system for the changes to take effect. This may impact functionality if Appletalk services are actively used.