huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
xsk: avoid data corruption on cq descriptor number
CVE: CVE-2025-40290
Component: kernel
Severity: None
Release date: 2025-12-08T00:00:00+00:00

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

xsk: avoid data corruption on cq descriptor number

Since commit 30f241fcf52a ("xsk: Fix immature cq descriptor
production"), the descriptor number is stored in skb control block and
xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto
pool's completion queue.

skb control block shouldn't be used for this purpose as after transmit
xsk doesn't have control over it and other subsystems could use it. This
leads to the following kernel panic due to a NULL pointer dereference.

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy)  Debian 6.16.12-1
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
 RIP: 0010:xsk_destruct_skb+0xd0/0x180
 [...]
 Call Trace:
  <IRQ>
  ? napi_complete_done+0x7a/0x1a0
  ip_rcv_core+0x1bb/0x340
  ip_rcv+0x30/0x1f0
  __netif_receive_skb_one_core+0x85/0xa0
  process_backlog+0x87/0x130
  __napi_poll+0x28/0x180
  net_rx_action+0x339/0x420
  handle_softirqs+0xdc/0x320
  ? handle_edge_irq+0x90/0x1e0
  do_softirq.part.0+0x3b/0x60
  </IRQ>
  <TASK>
  __local_bh_enable_ip+0x60/0x70
  __dev_direct_xmit+0x14e/0x1f0
  __xsk_generic_xmit+0x482/0xb70
  ? __remove_hrtimer+0x41/0xa0
  ? __xsk_generic_xmit+0x51/0xb70
  ? _raw_spin_unlock_irqrestore+0xe/0x40
  xsk_sendmsg+0xda/0x1c0
  __sys_sendto+0x1ee/0x200
  __x64_sys_sendto+0x24/0x30
  do_syscall_64+0x84/0x2f0
  ? __pfx_pollwake+0x10/0x10
  ? __rseq_handle_notify_resume+0xad/0x4c0
  ? restore_fpregs_from_fpstate+0x3c/0x90
  ? switch_fpu_return+0x5b/0xe0
  ? do_syscall_64+0x204/0x2f0
  ? do_syscall_64+0x204/0x2f0
  ? do_syscall_64+0x204/0x2f0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
  </TASK>
 [...]
 Kernel panic - not syncing: Fatal exception in interrupt
 Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Instead use the skb destructor_arg pointer along with pointer tagging.
As pointers are always aligned to 8B, use the bottom bit to indicate
whether this a single address or an allocated struct containing several
addresses.


Remediation:
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
CVE: CVE-2025-38058
Component: kernel
CWE: CWE-413
Severity: Moderate
CVSS v3: 6.3/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
Release date: 2025-06-18T00:00:00+00:00

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

__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock

... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().

Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.


Remediation:
gpiolib: Fix crash on error in gpiochip_get_ngpios()
CVE: CVE-2025-21783
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-02-27T00:00:00+00:00

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

gpiolib: Fix crash on error in gpiochip_get_ngpios()

The gpiochip_get_ngpios() uses chip_*() macros to print messages.
However these macros rely on gpiodev to be initialised and set,
which is not the case when called via bgpio_init(). In such a case
the printing messages will crash on NULL pointer dereference.
Replace chip_*() macros by the respective dev_*() ones to avoid
such crash.


Remediation:
Privilege Escalation in NVIDIA GPU Display Driver for Linux
CVE: CVE-2025-23244
Component: GPU
CVSS v3: 7.9/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-05-01T14:04:45.789000+00:00

A flaw was found in the NVIDIA GPU Display Driver for Linux. This vulnerability allows an unprivileged attacker to escalate privileges, execute arbitrary code, cause denial of service, disclose information, or tamper with data.

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:
A Recursor configured to send out ECS enabled queries can be sensitive to spoofing attempts
CVE: CVE-2025-30192
Component: pdns-recursor
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-07-21T12:49:31.532000+00:00

A denial of service flaw haws been discovered in powerdns. An attacker spoofing answers to ECS enabled requests sent out by the Recursor has a higher chance of success than non-ECS enabled queries.

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.
Linux kernel: Denial of Service via improper pointer initialization
CVE: CVE-2025-38408
Component: kernel
CWE: CWE-824
Severity: Moderate
CVSS v3: 4.4/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-07-25T00:00:00+00:00

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

genirq/irq_sim: Initialize work context pointers properly

Initialize `ops` member's pointers properly by using kzalloc() instead of
kmalloc() when allocating the simulation work context. Otherwise the
pointers contain random content leading to invalid dereferencing.


Remediation:
net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets
CVE: CVE-2025-21629
Component: kernel
CWE: CWE-354
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-15T00:00:00+00:00

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

net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets

The blamed commit disabled hardware offoad of IPv6 packets with
extension headers on devices that advertise NETIF_F_IPV6_CSUM,
based on the definition of that feature in skbuff.h:

 *   * - %NETIF_F_IPV6_CSUM
 *     - Driver (device) is only able to checksum plain
 *       TCP or UDP packets over IPv6. These are specifically
 *       unencapsulated packets of the form IPv6|TCP or
 *       IPv6|UDP where the Next Header field in the IPv6
 *       header is either TCP or UDP. IPv6 extension headers
 *       are not supported with this feature. This feature
 *       cannot be set in features for a device with
 *       NETIF_F_HW_CSUM also set. This feature is being
 *       DEPRECATED (see below).

The change causes skb_warn_bad_offload to fire for BIG TCP
packets.

[  496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0

[  496.310297]  ? skb_warn_bad_offload+0xc4/0xe0
[  496.310300]  skb_checksum_help+0x129/0x1f0
[  496.310303]  skb_csum_hwoffload_help+0x150/0x1b0
[  496.310306]  validate_xmit_skb+0x159/0x270
[  496.310309]  validate_xmit_skb_list+0x41/0x70
[  496.310312]  sch_direct_xmit+0x5c/0x250
[  496.310317]  __qdisc_run+0x388/0x620

BIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to
communicate packet length, as this is an IPv6 jumbogram. But, the
feature is only enabled on devices that support BIG TCP TSO. The
header is only present for PF_PACKET taps like tcpdump, and not
transmitted by physical devices.

For this specific case of extension headers that are not
transmitted, return to the situation before the blamed commit
and support hardware offload.

ipv6_has_hopopt_jumbo() tests not only whether this header is present,
but also that it is the only extension header before a terminal (L4)
header.


Remediation:
GNU Binutils ld libbfd.c bfd_putl64 memory corruption
CVE: CVE-2025-1179
Component: binutils
CWE: CWE-119
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-11T07:00:10.602000+00:00

A flaw was found in GNU Binutils. This vulnerability allows memory corruption via manipulation of the bfd_putl64 function.


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.
LoongArch: BPF: Disable trampoline for kernel module function trace
CVE: CVE-2025-68216
Component: kernel
Severity: None
Release date: 2025-12-16T00:00:00+00:00

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

LoongArch: BPF: Disable trampoline for kernel module function trace

The current LoongArch BPF trampoline implementation is incompatible
with tracing functions in kernel modules. This causes several severe
and user-visible problems:

* The `bpf_selftests/module_attach` test fails consistently.
* Kernel lockup when a BPF program is attached to a module function [1].
* Critical kernel modules like WireGuard experience traffic disruption
  when their functions are traced with fentry [2].

Given the severity and the potential for other unknown side-effects, it
is safest to disable the feature entirely for now. This patch prevents
the BPF subsystem from allowing trampoline attachments to kernel module
functions on LoongArch.

This is a temporary mitigation until the core issues in the trampoline
code for kernel module handling can be identified and fixed.

[root@fedora bpf]# ./test_progs -a module_attach -v
bpf_testmod.ko is already unloaded.
Loading bpf_testmod.ko...
Successfully loaded bpf_testmod.ko.
test_module_attach:PASS:skel_open 0 nsec
test_module_attach:PASS:set_attach_target 0 nsec
test_module_attach:PASS:set_attach_target_explicit 0 nsec
test_module_attach:PASS:skel_load 0 nsec
libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP
libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP
test_module_attach:FAIL:skel_attach skeleton attach failed: -524
Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
Successfully unloaded bpf_testmod.ko.

[1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/
[2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/


Remediation:
Out of bounds reads in soup_headers_parse_request()
CVE: CVE-2025-32906
Component: libsoup
CWE: CWE-125
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-04-14T00:00:00+00:00

A flaw was found in libsoup, where the soup_headers_parse_request() function may be vulnerable to an out-of-bound read. This flaw allows a malicious user to use a specially crafted HTTP request to crash the HTTP server.


Remediation:
Currently, no mitigation was found for this vulnerability.
GStreamer Subparse Stack Buffer Overflow
CVE: CVE-2025-47806
Component: gstreamer1-plugins-base
CWE: CWE-125
Severity: Moderate
CVSS v3: 5.6/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-08-07T00:00:00+00:00

A flaw was found in gstreamer1-plugins-base. The subparse plugin's `parse_subrip_time` function contains a stack buffer overflow due to insufficient bounds checking when processing subtitle data. This vulnerability allows a local attacker to provide a specially crafted subtitle file, causing a buffer overflow that can result in a program crash.


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.
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
CVE: CVE-2025-22005
Component: kernel
CWE: CWE-401
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L
Release date: 2025-04-03T00:00:00+00:00

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

ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().

fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything
when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")
moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()
but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in
case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.

Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the
error path.

Note that we can remove the fib6_nh_release() call in nh_create_ipv6()
later in net-next.git.


Remediation:
mISDN: hfcpci: Fix warning when deleting uninitialized timer
CVE: CVE-2025-39833
Component: kernel
CWE: CWE-665
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-09-16T00:00:00+00:00

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

mISDN: hfcpci: Fix warning when deleting uninitialized timer

With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads
to the following splat:

[  250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0
[  250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0
[  250.218775] Modules linked in: hfcpci(-) mISDN_core
[  250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)
[  250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0
[  250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d
[  250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286
[  250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95
[  250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0
[  250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39
[  250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001
[  250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8
[  250.232454] FS:  00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000
[  250.233851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0
[  250.236117] Call Trace:
[  250.236599]  <TASK>
[  250.236967]  ? trace_irq_enable.constprop.0+0xd4/0x130
[  250.237920]  debug_object_assert_init+0x1f6/0x310
[  250.238762]  ? __pfx_debug_object_assert_init+0x10/0x10
[  250.239658]  ? __lock_acquire+0xdea/0x1c70
[  250.240369]  __try_to_del_timer_sync+0x69/0x140
[  250.241172]  ? __pfx___try_to_del_timer_sync+0x10/0x10
[  250.242058]  ? __timer_delete_sync+0xc6/0x120
[  250.242842]  ? lock_acquire+0x30/0x80
[  250.243474]  ? __timer_delete_sync+0xc6/0x120
[  250.244262]  __timer_delete_sync+0x98/0x120
[  250.245015]  HFC_cleanup+0x10/0x20 [hfcpci]
[  250.245704]  __do_sys_delete_module+0x348/0x510
[  250.246461]  ? __pfx___do_sys_delete_module+0x10/0x10
[  250.247338]  do_syscall_64+0xc1/0x360
[  250.247924]  entry_SYSCALL_64_after_hwframe+0x77/0x7f

Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.
Also, use mod_timer instead of manual timeout update.

Statement: The hfcpci driver could attempt to delete an uninitialized timer during module unload, triggering debug warnings and a possible crash on debug builds. The fix initializes the timer with DEFINE_TIMER() and uses mod_timer() instead of manually manipulating expires. This is a low-risk, local issue requiring privileged access and primarily affects unload/debug paths rather than normal runtime.

Remediation:
netfilter: ctnetlink: fix refcount leak on table dump
CVE: CVE-2025-38721
Component: kernel
CWE: CWE-911
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-09-04T00:00:00+00:00

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlink_dump_table():
      if (res < 0) {
                nf_conntrack_get(&ct->ct_general); // HERE
                cb->args[1] = (unsigned long)ct;
                ...

While its very unlikely, its possible that ct == last.
If this happens, then the refcount of ct was already incremented.
This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn
keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as
nf_conntrack_cleanup_net_list() will wait forever.

This can be reproduced by running conntrack_resize.sh selftest in a loop.
It takes ~20 minutes for me on a preemptible kernel on average before
I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.

One fix would to change this to:
        if (res < 0) {
		if (ct != last)
	                nf_conntrack_get(&ct->ct_general);

But this reference counting isn't needed in the first place.
We can just store a cookie value instead.

A followup patch will do the same for ctnetlink_exp_dump_table,
it looks to me as if this has the same problem and like
ctnetlink_dump_table, we only need a 'skip hint', not the actual
object so we can apply the same cookie strategy there as well.

Statement: A refcount leak in ctnetlink_dump_table() could pin a conntrack entry and prevent the conntrack table count from dropping to zero, stalling netns teardown or conntrack module removal (kernel worker spins in cleanup). Exploitation is local and generally requires CAP_NET_ADMIN to trigger table dumps.

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.
out-of-bounds read via a crafted 0x01 response from an MMS server
CVE: CVE-2025-51602
Component: vlc
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-01-01T00:00:00+00:00

mmstu.c in VideoLAN VLC media player before 3.0.22 allows an out-of-bounds read and denial of service via a crafted 0x01 response from an MMS server.

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:
ASoC: qcom: audioreach: fix potential null pointer dereference
CVE: CVE-2025-40013
Component: kernel
Severity: None
Release date: 2025-10-20T00:00:00+00:00

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

ASoC: qcom: audioreach: fix potential null pointer dereference

It is possible that the topology parsing function
audioreach_widget_load_module_common() could return NULL or an error
pointer. Add missing NULL check so that we do not dereference it.


Remediation:
Optimizer unspecified vulnerability (CPU Jan 2025)
CVE: CVE-2025-21500
Component: mysql
Severity: Moderate
CVSS v3: 6.7/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-21T20:52:55.678000+00:00

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


Remediation:
Incorrect boundary conditions in the Graphics: WebGPU component
CVE: CVE-2025-13021
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:13.214000+00:00

Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145 and Thunderbird < 145.

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

Remediation:
Inappropriate implementation in Fenced Frames
CVE: CVE-2025-0441
Component: chromium-browser
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Release date: 2025-01-15T10:58:53.709000+00:00

Inappropriate implementation in Fenced Frames in Google Chrome prior to 132.0.6834.83 allowed a remote attacker to obtain potentially sensitive information from the system via a crafted HTML page. (Chromium security severity: Medium)

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:
cpp-httplib memory leak
CVE: CVE-2025-52887
Component: cpp-httplib
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-06-26T14:31:52.092000+00:00

A denial-of-service vulnerability, stemming from memory exhaustion, has been identified in the cpp-httplib C++ HTTP/HTTPS library. This flaw is a result of the library's insufficient limits on the processing of HTTP headers. A remote attacker could exploit this by sending specially crafted HTTP requests with overly large or numerous headers, causing excessive memory consumption and ultimately leading to a program crash. This impacts the availability and stability of applications using cpp-httplib.

Statement: On Red Hat systems, any memory exhaustion will lead to the host operating system killing the offending program. The host system will continue operation.

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.
OpenEXR NULL pointer dereference
CVE: CVE-2025-48073
Component: openexr
CWE: CWE-476
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-07-31T20:25:51.545000+00:00

A NULL pointer dereference flaw was found in OpenEXR. When reading a deep scanline image with a large sample count in reduceMemory mode, it is possible to crash a target application with a NULL pointer dereference in a write operation.


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.