huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
FontForge: Remote Code Execution via malicious SGI file parsing
CVE: CVE-2025-15277
Component: fontforge
CWE: CWE-122
Severity: Important
CVSS v3: 7.7/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-12-31T06:59:29.183000+00:00

A flaw was found in FontForge. This vulnerability, a heap-based buffer overflow, allows a remote attacker to execute arbitrary code. Exploitation requires user interaction, such as opening a malicious SGI (Silicon Graphics Image) file, which triggers improper data length validation during scanline parsing, leading to memory corruption.

Statement: This vulnerability is rated Important for Red Hat products. Exploitation requires user interaction, specifically opening a specially crafted SGI file in FontForge. This impacts systems where FontForge is installed and used to process untrusted image files, such as in desktop environments.

Remediation:
Avoid opening untrusted SGI (Silicon Graphics Image) files with FontForge. If FontForge is not essential for system operation, consider removing the package to eliminate the attack surface.

To remove FontForge:
For Red Hat Enterprise Linux 7 and 8:
`sudo yum remove fontforge`
For Red Hat Enterprise Linux 9 and 10, and Fedora:
`sudo dnf remove fontforge`

Removing FontForge may affect other applications that depend on its functionality. A system restart may be required to ensure all related processes are terminated.
ibmvnic: Use kernel helpers for hex dumps
CVE: CVE-2025-22104
Component: kernel
CWE: CWE-120
Severity: Moderate
CVSS v3: 7.2/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Release date: 2025-04-16T00:00:00+00:00

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

ibmvnic: Use kernel helpers for hex dumps

Previously, when the driver was printing hex dumps, the buffer was cast
to an 8 byte long and printed using string formatters. If the buffer
size was not a multiple of 8 then a read buffer overflow was possible.

Therefore, create a new ibmvnic function that loops over a buffer and
calls hex_dump_to_buffer instead.

This patch address KASAN reports like the one below:
  ibmvnic 30000003 env3: Login Buffer:
  ibmvnic 30000003 env3: 01000000af000000
  <...>
  ibmvnic 30000003 env3: 2e6d62692e736261
  ibmvnic 30000003 env3: 65050003006d6f63
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]
  Read of size 8 at addr c0000001331a9aa8 by task ip/17681
  <...>
  Allocated by task 17681:
  <...>
  ibmvnic_login+0x2f0/0xffc [ibmvnic]
  ibmvnic_open+0x148/0x308 [ibmvnic]
  __dev_open+0x1ac/0x304
  <...>
  The buggy address is located 168 bytes inside of
                allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)
  <...>
  =================================================================
  ibmvnic 30000003 env3: 000000000033766e


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.
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.
eth: bnxt: always recalculate features after XDP clearing, fix null-deref
CVE: CVE-2025-21682
Component: kernel
CWE: CWE-476
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-31T00:00:00+00:00

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

eth: bnxt: always recalculate features after XDP clearing, fix null-deref

Recalculate features when XDP is detached.

Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]

After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on

The fact that HW-GRO doesn't get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn't handle reconfiguring
two things at a time very robustly.

Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") we only reconfigure the RSS hash table
if the "effective" number of Rx rings has changed. If HW-GRO is
enabled "effective" number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement "pending"
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:

  if (old_rx_rings != bp->hw_resc.resv_rx_rings &&

condition in __bnxt_reserve_rings() will be false.
The RSS map won't get updated, and we'll crash with:

  BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0
    bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180
    __bnxt_setup_vnic_p5+0x58/0x110
    bnxt_init_nic+0xb72/0xf50
    __bnxt_open_nic+0x40d/0xab0
    bnxt_open_nic+0x2b/0x60
    ethtool_set_channels+0x18c/0x1d0

As we try to access a freed ring.

The issue is present since XDP support was added, really, but
prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") it wasn't causing major issues.


Remediation:
Suricata: Unbounded memory growth via compressed HTTP data
CVE: CVE-2025-64334
Component: Suricata
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-26T22:39:15.552000+00:00

A flaw was found in Suricata. This vulnerability allows unbounded memory growth during decompression via compressed HTTP data.

Statement: The highest threat is to system availability due to unbounded memory growth when processing compressed HTTP data. This issue affects Suricata when configured to inspect HTTP traffic that includes compressed content.

Remediation:
net: tls: explicitly disallow disconnect
CVE: CVE-2025-37756
Component: kernel
CWE: CWE-20
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-05-01T00:00:00+00:00

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

net: tls: explicitly disallow disconnect

syzbot discovered that it can disconnect a TLS socket and then
run into all sort of unexpected corner cases. I have a vague
recollection of Eric pointing this out to us a long time ago.
Supporting disconnect is really hard, for one thing if offload
is enabled we'd need to wait for all packets to be _acked_.
Disconnect is not commonly used, disallow it.

The immediate problem syzbot run into is the warning in the strp,
but that's just the easiest bug to trigger:

  WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
  RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
  Call Trace:
   <TASK>
   tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363
   tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043
   inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678
   sock_recvmsg_nosec net/socket.c:1023 [inline]
   sock_recvmsg+0x109/0x280 net/socket.c:1045
   __sys_recvfrom+0x202/0x380 net/socket.c:2237


Remediation:
authenticated attackers can potentially bypass authorization restrictions
CVE: CVE-2025-30093
Component: condor
CVSS v3: 6.5/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-03-27T00:00:00+00:00

HTCondor 23.0.x before 23.0.22, 23.10.x before 23.10.22, 24.0.x before 24.0.6, and 24.6.x before 24.6.1 allows authenticated attackers to bypass authorization restrictions.

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:
NVIDIA Display Driver out of bound read
CVE: CVE-2025-23345
Component: nvidia-display-driver
CWE: CWE-125
Severity: Moderate
CVSS v3: 6.7/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
Release date: 2025-10-23T18:25:48.962000+00:00

NVIDIA Display Driver for Windows and Linux contains a vulnerability in a video decoder, where an attacker might cause an out-of-bounds read. A successful exploit of this vulnerability might lead to information disclosure or denial of service.


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.
wifi: mac80211: reject VHT opmode for unsupported channel widths
CVE: CVE-2025-38509
Component: kernel
Severity: Important
CVSS v3: 7.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-08-16T00:00:00+00:00

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

wifi: mac80211: reject VHT opmode for unsupported channel widths

VHT operating mode notifications are not defined for channel widths
below 20 MHz. In particular, 5 MHz and 10 MHz are not valid under the
VHT specification and must be rejected.

Without this check, malformed notifications using these widths may
reach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due to
invalid input. This issue was reported by syzbot.

Reject these unsupported widths early in sta_link_apply_parameters()
when opmode_notif is used. The accepted set includes 20, 40, 80, 160,
and 80+80 MHz, which are valid for VHT. While 320 MHz is not defined
for VHT, it is allowed to avoid rejecting HE or EHT clients that may
still send a VHT opmode notification.


Remediation:
Alt-Svc ALPN validation failure when redirected
CVE: CVE-2025-0239
Component: firefox
CWE: CWE-601
Severity: Moderate
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Release date: 2025-01-07T16:07:06.317000+00:00

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: When using Alt-Svc, ALPN did not properly validate certificates when the original server is redirecting to an insecure site.

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

Remediation:
bpf: Send signals asynchronously if !preemptible
CVE: CVE-2025-21728
Component: kernel
CWE: CWE-20
Severity: Moderate
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:

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change `irqs_disabled()` to `!preemptible()`.


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.
Kibana Open Redirect
CVE: CVE-2025-25012
Component: kibana
CWE: CWE-601
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-06-25T11:52:53.699000+00:00

URL redirection to an untrusted site ('Open Redirect') in Kibana can lead to sending a user to an arbitrary site and server-side request forgery via a specially crafted URL.


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.
media: imon: make send_packet() more robust
CVE: CVE-2025-68194
Component: kernel
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:

media: imon: make send_packet() more robust

syzbot is reporting that imon has three problems which result in
hung tasks due to forever holding device lock [1].

First problem is that when usb_rx_callback_intf0() once got -EPROTO error
after ictx->dev_present_intf0 became true, usb_rx_callback_intf0()
resubmits urb after printk(), and resubmitted urb causes
usb_rx_callback_intf0() to again get -EPROTO error. This results in
printk() flooding (RCU stalls).

Alan Stern commented [2] that

  In theory it's okay to resubmit _if_ the driver has a robust
  error-recovery scheme (such as giving up after some fixed limit on the
  number of errors or after some fixed time has elapsed, perhaps with a
  time delay to prevent a flood of errors).  Most drivers don't bother to
  do this; they simply give up right away.  This makes them more
  vulnerable to short-term noise interference during USB transfers, but in
  reality such interference is quite rare.  There's nothing really wrong
  with giving up right away.

but imon has a poor error-recovery scheme which just retries forever;
this behavior should be fixed.

Since I'm not sure whether it is safe for imon users to give up upon any
error code, this patch takes care of only union of error codes chosen from
modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.
ir_toy, mceusb and igorplugusb).

Second problem is that when usb_rx_callback_intf0() once got -EPROTO error
before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always
resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge
hardware after early callbacks"). Move the ictx->dev_present_intf0 test
introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes
until intf configured") to immediately before imon_incoming_packet(), or
the first problem explained above happens without printk() flooding (i.e.
hung task).

Third problem is that when usb_rx_callback_intf0() is not called for some
reason (e.g. flaky hardware; the reproducer for this problem sometimes
prevents usb_rx_callback_intf0() from being called),
wait_for_completion_interruptible() in send_packet() never returns (i.e.
hung task). As a workaround for such situation, change send_packet() to
wait for completion with timeout of 10 seconds.


Remediation:
pds_core: make wait_context part of q_info
CVE: CVE-2025-37886
Component: kernel
Severity: None
Release date: 2025-05-09T00:00:00+00:00

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

pds_core: make wait_context part of q_info

Make the wait_context a full part of the q_info struct rather
than a stack variable that goes away after pdsc_adminq_post()
is done so that the context is still available after the wait
loop has given up.

There was a case where a slow development firmware caused
the adminq request to time out, but then later the FW finally
finished the request and sent the interrupt.  The handler tried
to complete_all() the completion context that had been created
on the stack in pdsc_adminq_post() but no longer existed.
This caused bad pointer usage, kernel crashes, and much wailing
and gnashing of teeth.


Remediation:
HID: corsair-void: Update power supply values with a unified work handler
CVE: CVE-2025-21952
Component: kernel
Severity: None
Release date: 2025-04-01T00:00:00+00:00

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

HID: corsair-void: Update power supply values with a unified work handler

corsair_void_process_receiver can be called from an interrupt context,
locking battery_mutex in it was causing a kernel panic.
Fix it by moving the critical section into its own work, sharing this
work with battery_add_work and battery_remove_work to remove the need
for any locking


Remediation:
Traffic Server ESI Inclusion Depth Vulnerability
CVE: CVE-2025-49763
Component: trafficserver
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-06-19T10:07:15.450000+00:00

A flaw was found in trafficserver. The Edge Side Includes (ESI) plugin lacks a limit on maximum inclusion depth, allowing a remote attacker to trigger excessive memory consumption by inserting malicious instructions. This condition occurs due to the plugin's inability to restrict the nesting of ESI includes, potentially leading to a denial of service. The vulnerability is triggered via a crafted ESI request.

Statement: This issue is rated as Important because it allows a remote, unauthenticated attacker to impact the availability of the service without requiring user interaction. While it requires a specific plugin to be enabled, ESI is a common feature for environments that serve dynamic content. The vulnerability does not lead to a compromise of confidentiality or integrity, preventing a "Critical" rating. Apache Traffic Server is primarily available in Red Hat environments through the community-supported EPEL repository, which is a key factor in this assessment.

Remediation:
To mitigate this flaw use a new setting for the plugin (--max-inclusion-depth) to limit it.
smb: client: let smbd_destroy() call disable_work_sync(&#38;info->post_send_credits_work)
CVE: CVE-2025-39932
Component: kernel
CWE: CWE-362
Severity: Moderate
CVSS v3: 5.7/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-10-04T00:00:00+00:00

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

smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)

In smbd_destroy() we may destroy the memory so we better
wait until post_send_credits_work is no longer pending
and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]
...
[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]
[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30
[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]
[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60
[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]
[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]
[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]
[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10
[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0
[ 5305.687889] [    T138]  process_one_work+0x629/0xf80
[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30
[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570
...

It means rxe_post_recv was called after rdma_destroy_qp().
This happened because put_receive_buffer() was triggered
by ib_drain_qp() and called:
queue_work(info->workqueue, &info->post_send_credits_work);

Statement: A race in the SMB Direct client allowed post_send_credits_work to be queued/run after RDMA resources were destroyed in smbd_destroy(), potentially leading to a kernel use-after-free and system crash. A malicious SMB server reachable over RDMA (including SoftRoCE/rxe) could trigger client-side DoS once an SMB Direct session exists (so the attack from server to client only could be).

Remediation:
zloop: fix KASAN use-after-free of tag set
CVE: CVE-2025-38620
Component: kernel
CWE: CWE-416
Severity: None
Release date: 2025-08-22T00:00:00+00:00

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

zloop: fix KASAN use-after-free of tag set

When a zoned loop device, or zloop device, is removed, KASAN enabled
kernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The
BUG happens because zloop_ctl_remove() calls put_disk(), which invokes
zloop_free_disk(). The zloop_free_disk() frees the memory allocated for
the zlo pointer. However, after the memory is freed, zloop_ctl_remove()
calls blk_mq_free_tag_set(&zlo->tag_set), which accesses the freed zlo.
Hence the KASAN use-after-free.

 zloop_ctl_remove()
  put_disk(zlo->disk)
   put_device()
    kobject_put()
     ...
      zloop_free_disk()
        kvfree(zlo)
  blk_mq_free_tag_set(&zlo->tag_set)

To avoid the BUG, move the call to blk_mq_free_tag_set(&zlo->tag_set)
from zloop_ctl_remove() into zloop_free_disk(). This ensures that
the tag_set is freed before the call to kvfree(zlo).


Remediation:
CVE: CVE-2025-7285
Component: IrfanView CADImage Plugin DXF File Parsing Memory Corruption Remote Code Execution Vulnerability
Release date: 2025-07-08T19:58:52.323000+00:00

IrfanView CADImage Plugin DXF File Parsing Memory Corruption Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of IrfanView CADImage Plugin. 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 DXF files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26221.

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:
net: drv: netdevsim: don't napi_complete() from netpoll
CVE: CVE-2025-38270
Component: kernel
CWE: CWE-672
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-10T00:00:00+00:00

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

net: drv: netdevsim: don't napi_complete() from netpoll

netdevsim supports netpoll. Make sure we don't call napi_complete()
from it, since it may not be scheduled. Breno reports hitting a
warning in napi_complete_done():

WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560
  __napi_poll+0x2d8/0x3a0
  handle_softirqs+0x1fe/0x710

This is presumably after netpoll stole the SCHED bit prematurely.

Statement: A missing check in the netdevsim NAPI poll function could lead to a warning or soft crash when used with netpoll, due to premature calls to napi_complete() without verifying scheduling state. This issue is mitigated by replacing the call with napi_complete_done() only if the budget is not exceeded. While the issue is non-exploitable in practice and difficult to trigger, it can impact system availability.

Remediation: