huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
Conda-build supply chain confusion
CVE: CVE-2025-32800
Component: conda-build
CVSS v3: 8.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-06-16T20:38:53.100000+00:00

The Conda-build contains commands and tools to build Conda packages. Prior to version 25.3.0, the pyproject.toml lists conda-index as a Python dependency. This package is not published in PyPI. This flaw allows an attacker to claim this namespace, upload arbitrary (malicious) code to the package, and then exploit pip install commands by injecting the malicious dependency into the build.

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.
acpi: typec: ucsi: Introduce a ->poll_cci method
CVE: CVE-2025-21902
Component: kernel
CWE: CWE-662
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-04-01T00:00:00+00:00

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

acpi: typec: ucsi: Introduce a ->poll_cci method

For the ACPI backend of UCSI the UCSI "registers" are just a memory copy
of the register values in an opregion. The ACPI implementation in the
BIOS ensures that the opregion contents are synced to the embedded
controller and it ensures that the registers (in particular CCI) are
synced back to the opregion on notifications. While there is an ACPI call
that syncs the actual registers to the opregion there is rarely a need to
do this and on some ACPI implementations it actually breaks in various
interesting ways.

The only reason to force a sync from the embedded controller is to poll
CCI while notifications are disabled. Only the ucsi core knows if this
is the case and guessing based on the current command is suboptimal, i.e.
leading to the following spurious assertion splat:

WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023
Workqueue: events_long ucsi_init_work [typec_ucsi]
RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
Call Trace:
 <TASK>
 ucsi_init_work+0x3c/0xac0 [typec_ucsi]
 process_one_work+0x179/0x330
 worker_thread+0x252/0x390
 kthread+0xd2/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Thus introduce a ->poll_cci() method that works like ->read_cci() with an
additional forced sync and document that this should be used when polling
with notifications disabled. For all other backends that presumably don't
have this issue use the same implementation for both methods.


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.
ext4: only dirty folios when data journaling regular files
CVE: CVE-2025-38220
Component: kernel
CWE: CWE-476
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-07-04T00:00:00+00:00

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

ext4: only dirty folios when data journaling regular files

fstest generic/388 occasionally reproduces a crash that looks as
follows:

BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
 <TASK>
 ext4_block_zero_page_range+0x30c/0x380 [ext4]
 ext4_truncate+0x436/0x440 [ext4]
 ext4_process_orphan+0x5d/0x110 [ext4]
 ext4_orphan_cleanup+0x124/0x4f0 [ext4]
 ext4_fill_super+0x262d/0x3110 [ext4]
 get_tree_bdev_flags+0x132/0x1d0
 vfs_get_tree+0x26/0xd0
 vfs_cmd_create+0x59/0xe0
 __do_sys_fsconfig+0x4ed/0x6b0
 do_syscall_64+0x82/0x170
 ...

This occurs when processing a symlink inode from the orphan list. The
partial block zeroing code in the truncate path calls
ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls
mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an
a_ops vector in ext4, hence the crash.

To avoid this problem, update the ext4_dirty_journalled_data() helper to
only mark the folio dirty on regular files (for which a_ops is
assigned). This also matches the journaling logic in the ext4_symlink()
creation path, where ext4_handle_dirty_metadata() is called directly.


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.
FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding
CVE: CVE-2025-59733
Component: FFmpeg
CVSS v3: 6.4/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-10-06T08:09:37.290000+00:00

A flaw was found in FFmpeg. This vulnerability allows a buffer overflow via a specially crafted OpenEXR (EXR) file using DWAA (DreamWorks Animation Adaptive) or DWAB (DreamWorks Animation B-wave) compression, due to incorrect handling of image channel pixel types during decoding.

Statement: The highest threat is to system availability, as processing a specially crafted OpenEXR file with DWAA/DWAB compression can lead to a buffer overflow in FFmpeg, resulting in a denial of service. This requires an attacker to be on the same adjacent network.

Remediation:
Address of e-mail sender can be spoofed by malicious email
CVE: CVE-2025-0510
Component: thunderbird
CWE: CWE-451
Severity: Important
CVSS v3: 7.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N
Release date: 2025-02-04T13:58:55.320000+00:00

A flaw was found in Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue: Thunderbird displayed an incorrect sender address if the From field of an email used the invalid group name syntax that is described in CVE-2024-49040.

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

Remediation:
rxrpc: Fix untrusted unsigned subtract
CVE: CVE-2025-39962
Component: kernel
Severity: None
Release date: 2025-10-09T00:00:00+00:00

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

rxrpc: Fix untrusted unsigned subtract

Fix the following Smatch static checker warning:

   net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket()
   warn: untrusted unsigned subtract. 'ticket_len - 10 * 4'

by prechecking the length of what we're trying to extract in two places in
the token and decoding for a response packet.

Also use sizeof() on the struct we're extracting rather specifying the size
numerically to be consistent with the other related statements.


Remediation:
arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
CVE: CVE-2025-38670
Component: kernel
Severity: None
Release date: 2025-08-22T00:00:00+00:00

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

arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()

`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change
to different stacks along with the Shadow Call Stack if it is enabled.
Those two stack changes cannot be done atomically and both functions
can be interrupted by SErrors or Debug Exceptions which, though unlikely,
is very much broken : if interrupted, we can end up with mismatched stacks
and Shadow Call Stack leading to clobbered stacks.

In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,
but x18 stills points to the old task's SCS. When the interrupt handler
tries to save the task's SCS pointer, it will save the old task
SCS pointer (x18) into the new task struct (pointed to by SP_EL0),
clobbering it.

In `call_on_irq_stack()`, it can happen when switching from the task stack
to the IRQ stack and when switching back. In both cases, we can be
interrupted when the SCS pointer points to the IRQ SCS, but SP points to
the task stack. The nested interrupt handler pushes its return addresses
on the IRQ SCS. It then detects that SP points to the task stack,
calls `call_on_irq_stack()` and clobbers the task SCS pointer with
the IRQ SCS pointer, which it will also use !

This leads to tasks returning to addresses on the wrong SCS,
or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK
or FPAC if enabled.

This is possible on a default config, but unlikely.
However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and
instead the GIC is responsible for filtering what interrupts the CPU
should receive based on priority.
Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU
even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*
frequently depending on the system configuration and workload, leading
to unpredictable kernel panics.

Completely mask DAIF in `cpu_switch_to()` and restore it when returning.
Do the same in `call_on_irq_stack()`, but restore and mask around
the branch.
Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency
of behaviour between all configurations.

Introduce and use an assembly macro for saving and masking DAIF,
as the existing one saves but only masks IF.


Remediation:
null pointer dereference leads to denial of service
CVE: CVE-2025-2487
Component: 389-ds-base
CWE: CWE-476
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-03-18T00:00:00+00:00

A flaw was found in the 389-ds-base LDAP Server. This issue occurs when issuing a Modify DN LDAP operation through the ldap protocol, when the function return value is not tested and a NULL pointer is dereferenced. If a privileged user performs a ldap MODDN operation after a failed operation, it could lead to a Denial of Service (DoS) or system crash.

Statement: Red Hat rates this as a Moderate severity since the impact is limited to privileged users who can perform the operations, leading to an impact on server Availability.

This issue is not reproducible in Red Hat Enterprise Linux (RHEL) 10 due to the way the RHEL 10 database write operations are serialized, therefore, it is not affected.

389-ds-base has been fixed in RHEL 9.5. Starting from RHDS 12.5, it uses 389-ds-base from RHEL-9.5. Hence, it's actually not-affected and fix will be picked after rebase from RHEL-9.5.

Remediation:
Currently, no mitigation is available for this vulnerability.
ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT
CVE: CVE-2025-40142
Component: kernel
CWE: CWE-833
Severity: Moderate
CVSS v3: 5.9/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
Release date: 2025-11-12T00:00:00+00:00

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

ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT

snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts
via spin_lock_irq(). This also implicitly disables the handling of
softirqs such as TIMER_SOFTIRQ.
On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not
disable them. That means a timer can be invoked during spin_lock_irq()
on the same CPU. Due to synchronisations reasons local_bh_disable() has
a per-CPU lock named softirq_ctrl.lock which synchronizes individual
softirq against each other.
syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is
acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This
is a possible deadlock.

The softirq_ctrl.lock can not be made part of spin_lock_irq() as this
would lead to too much synchronisation against individual threads on the
system. To avoid the possible deadlock, softirqs must be manually
disabled before the lock is acquired.

Disable softirqs before the lock is acquired on PREEMPT_RT.


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.
Integer Overflow in Cookie Expiration Date Handling in libsoup
CVE: CVE-2025-4945
Component: libsoup
CWE: CWE-190
Severity: Low
CVSS v3: 3.6/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Release date: 2025-05-19T00:00:00+00:00

A flaw was found in the cookie parsing logic of the libsoup HTTP library, used in GNOME applications and other software. The vulnerability arises when processing the expiration date of cookies, where a specially crafted value can trigger an integer overflow. This may result in undefined behavior, allowing an attacker to bypass cookie expiration logic, causing persistent or unintended cookie behavior. The issue stems from improper validation of large integer inputs during date arithmetic operations within the cookie parsing routines.

Statement: The Red Hat Product Security team has assessed the severity of this vulnerability as Low. This assessment is based on the fact that successful exploitation requires an attacker to control or manipulate the expiration date of cookies sent from a malicious or compromised HTTP server. Additionally, the consequences of a successful attack are limited in scope affecting only the handling of cookie lifetimes within the local client instance, with no direct impact on system integrity, data confidentiality, or availability.

Remediation:
To mitigate the risk associated with this libsoup vulnerability, Red Hat recommends avoiding interactions between client applications using the libsoup library and untrusted or compromised HTTP servers until a patched version of libsoup is deployed. Users and administrators should monitor their systems for suspicious HTTP activity and apply vendor updates as soon as a fix becomes available to prevent manipulation of cookie expiration logic that could lead to unexpected behavior or policy circumvention.
Local DoS in OpenSMTPD via UNIX domain socket smtpd.sock
CVE: CVE-2025-62875
Component: opensmtpd
CVSS v3: 5.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Release date: 2025-11-20T16:02:11.542000+00:00

An Improper Check for Unusual or Exceptional Conditions vulnerability in OpenSMTPD allows local users to crash OpenSMTPD.




This issue affects openSUSE Tumbleweed: from ? before 7.8.0p0-1.1.

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.
netfs: fix reference leak
CVE: CVE-2025-40007
Component: kernel
CWE: CWE-911
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-10-20T00:00:00+00:00

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

netfs: fix reference leak

Commit 20d72b00ca81 ("netfs: Fix the request's work item to not
require a ref") modified netfs_alloc_request() to initialize the
reference counter to 2 instead of 1.  The rationale was that the
requet's "work" would release the second reference after completion
(via netfs_{read,write}_collection_worker()).  That works most of the
time if all goes well.

However, it leaks this additional reference if the request is released
before the I/O operation has been submitted: the error code path only
decrements the reference counter once and the work item will never be
queued because there will never be a completion.

This has caused outages of our whole server cluster today because
tasks were blocked in netfs_wait_for_outstanding_io(), leading to
deadlocks in Ceph (another bug that I will address soon in another
patch).  This was caused by a netfs_pgpriv2_begin_copy_to_cache() call
which failed in fscache_begin_write_operation().  The leaked
netfs_io_request was never completed, leaving `netfs_inode.io_count`
with a positive value forever.

All of this is super-fragile code.  Finding out which code paths will
lead to an eventual completion and which do not is hard to see:

- Some functions like netfs_create_write_req() allocate a request, but
  will never submit any I/O.

- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()
  and then netfs_put_request(); however, netfs_unbuffered_read() can
  also fail early before submitting the I/O request, therefore another
  netfs_put_request() call must be added there.

A rule of thumb is that functions that return a `netfs_io_request` do
not submit I/O, and all of their callers must be checked.

For my taste, the whole netfs code needs an overhaul to make reference
counting easier to understand and less fragile & obscure.  But to fix
this bug here and now and produce a patch that is adequate for a
stable backport, I tried a minimal approach that quickly frees the
request object upon early failure.

I decided against adding a second netfs_put_request() each time
because that would cause code duplication which obscures the code
further.  Instead, I added the function netfs_put_failed_request()
which frees such a failed request synchronously under the assumption
that the reference count is exactly 2 (as initially set by
netfs_alloc_request() and never touched), verified by a
WARN_ON_ONCE().  It then deinitializes the request object (without
going through the "cleanup_work" indirection) and frees the allocation
(with RCU protection to protect against concurrent access by
netfs_requests_seq_start()).

All code paths that fail early have been changed to call
netfs_put_failed_request() instead of netfs_put_request().
Additionally, I have added a netfs_put_request() call to
netfs_unbuffered_read() as explained above because the
netfs_put_failed_request() approach does not work there.


Remediation:
net: rose: include node references in rose_neigh refcount
CVE: CVE-2025-39827
Component: kernel
Severity: None
Release date: 2025-09-16T00:00:00+00:00

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

net: rose: include node references in rose_neigh refcount

Current implementation maintains two separate reference counting
mechanisms: the 'count' field in struct rose_neigh tracks references from
rose_node structures, while the 'use' field (now refcount_t) tracks
references from rose_sock.

This patch merges these two reference counting systems using 'use' field
for proper reference management. Specifically, this patch adds incrementing
and decrementing of rose_neigh->use when rose_neigh->count is incremented
or decremented.

This patch also modifies rose_rt_free(), rose_rt_device_down() and
rose_clear_route() to properly release references to rose_neigh objects
before freeing a rose_node through rose_remove_node().

These changes ensure rose_neigh structures are properly freed only when
all references, including those from rose_node structures, are released.
As a result, this resolves a slab-use-after-free issue reported by Syzbot.


Remediation:
Heap buffer overflow in Sync
CVE: CVE-2025-11458
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-06T22:26:49.076000+00:00

Heap buffer overflow in Sync in Google Chrome prior to 141.0.7390.65 allowed a remote attacker to perform an out of bounds memory read 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:
gve: prevent ethtool ops after shutdown
CVE: CVE-2025-38735
Component: kernel
CWE: CWE-664
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-05T00:00:00+00:00

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

gve: prevent ethtool ops after shutdown

A crash can occur if an ethtool operation is invoked
after shutdown() is called.

shutdown() is invoked during system shutdown to stop DMA operations
without performing expensive deallocations. It is discouraged to
unregister the netdev in this path, so the device may still be visible
to userspace and kernel helpers.

In gve, shutdown() tears down most internal data structures. If an
ethtool operation is dispatched after shutdown(), it will dereference
freed or NULL pointers, leading to a kernel panic. While graceful
shutdown normally quiesces userspace before invoking the reboot
syscall, forced shutdowns (as observed on GCP VMs) can still trigger
this path.

Fix by calling netif_device_detach() in shutdown().
This marks the device as detached so the ethtool ioctl handler
will skip dispatching operations to the driver.

Statement: After gve invokes shutdown() (e.g., during system/VM shutdown), most internal structures are torn down but the netdev may remain visible, so subsequent ethtool operations can dereference freed/NULL pointers and crash the kernel. Privilege escalation is considered highly unrealistic in this case, as the bug only manifests during system shutdown.

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.
iputils integer overflow
CVE: CVE-2025-48964
Component: iputils
CWE: CWE-190
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-07-22T00:00:00+00:00

An integer overflow flaw has been discovered in the ping function within the iputils package. This overflow may allow an attacker to craft an ECHO reply which can prevent iputils from operating normally.


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.
ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()
CVE: CVE-2025-21847
Component: kernel
CWE: CWE-476
Severity: Low
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-03-12T00:00:00+00:00

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

ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

The nullity of sps->cstream should be checked similarly as it is done in
sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps->stream is NULL is incorrect and can
lead to NULL pointer dereference.


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.