huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
jffs2: check that raw node were preallocated before writing summary
CVE: CVE-2025-38194
Component: kernel
CWE: CWE-252
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-07-04T00:00:00+00:00

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

jffs2: check that raw node were preallocated before writing summary

Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault
injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't
check return value of jffs2_prealloc_raw_node_refs and simply lets any
error propagate into jffs2_sum_write_data, which eventually calls
jffs2_link_node_ref in order to link the summary to an expectedly allocated
node.

kernel BUG at fs/jffs2/nodelist.c:592!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592
Call Trace:
 <TASK>
 jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]
 jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874
 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388
 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197
 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301
 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856
 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973
 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005
 call_write_iter include/linux/fs.h:2265 [inline]
 do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735
 do_iter_write+0x186/0x710 fs/read_write.c:861
 vfs_iter_write+0x70/0xa0 fs/read_write.c:902
 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685
 do_splice_from fs/splice.c:763 [inline]
 direct_splice_actor+0x10c/0x170 fs/splice.c:950
 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896
 do_splice_direct+0x1a9/0x280 fs/splice.c:1002
 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255
 __do_sys_sendfile64 fs/read_write.c:1323 [inline]
 __se_sys_sendfile64 fs/read_write.c:1309 [inline]
 __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Fix this issue by checking return value of jffs2_prealloc_raw_node_refs
before calling jffs2_sum_write_data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.


Remediation:
quic-go Has Panic in Path Probe Loss Recovery Handling
CVE: CVE-2025-29785
Component: quic-go
CWE: CWE-248
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-06-02T10:44:18.817000+00:00

A flaw was found in quic-go. This vulnerability allows a malicious QUIC client to cause a nil-pointer dereference, leading to an application-level denial of service via specially crafted ACK packets following spoofed path validation probes.

Statement: The severity of this vulnerability is rated Moderate, as it does not impact system availability. The effects are confined to the application layer, without compromising the underlying system stability.

Remediation:
Processing web content may lead to a denial-of-service
CVE: CVE-2025-24158
Component: webkitgtk
CWE: CWE-770
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-01-27T21:45:49.015000+00:00

A flaw was found in WebKitGTK. Processing malicious web content can cause a denial of service due to improper memory handling.

Statement: To exploit this flaw, an attacker needs to trick a user into processing or loading malicious web content.

Remediation:
Do not process or load untrusted web content with WebKitGTK.
comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large
CVE: CVE-2025-38481
Component: kernel
Severity: None
Release date: 2025-07-28T00:00:00+00:00

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

comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large

The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to
hold the array of `struct comedi_insn`, getting the length from the
`n_insns` member of the `struct comedi_insnlist` supplied by the user.
The allocation will fail with a WARNING and a stack dump if it is too
large.

Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`
value is unreasonable.

Define the limit on the `n_insns` value in the `MAX_INSNS` macro.  Set
this to the same value as `MAX_SAMPLES` (65536), which is the maximum
allowed sum of the values of the member `n` in the array of `struct
comedi_insn`, and sensible comedi instructions will have an `n` of at
least 1.


Remediation:
"NULL Pointer Dereference in ImageItem_iden in libheif
CVE: CVE-2025-43966
Component: libheif
CVSS v3: 2.8/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-04-20T00:00:00+00:00

A flaw was found in libheif. In affected versions, a NULL pointer dereference occurs in ImageItem_iden in image-items/iden.cc.

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.
wildfly-server: Wildfly improper RBAC permission
CVE: CVE-2025-23367
Component: org.wildfly.core
CWE: CWE-284
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-30T00:00:00+00:00

A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server. 
The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action.

Statement: Red Hat has evaluated this issue and the attacker must be authenticated as a user that belongs to the "Monitor" or "Auditor" management groups. It requires previous privileges to jeopardize an environment.

Remediation:
Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258
Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258
Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258
Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258
Before applying the update, make sure all previously released errata relevant to your system have been applied. Also, back up your existing installation, including all applications, configuration files, databases and database settings. 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.
Integer Overflow in libssh SFTP Server Packet Length Validation Leading to Denial of Service
CVE: CVE-2025-5449
Component: libssh
CWE: CWE-190
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-06-24T00:00:00+00:00

A flaw was found in the SFTP server message decoding logic of libssh. The issue occurs due to an incorrect packet length check that allows an integer overflow when handling large payload sizes on 32-bit systems. This issue leads to failed memory allocation and causes the server process to crash, resulting in a denial of service.

Statement: The Red Hat Product Security team has assessed the severity of this vulnerability as Moderate, given that it is only exploitable on 32-bit systems by authenticated users with SFTP access. The issue stems from an integer overflow in packet length validation that causes excessive memory allocation attempts, leading to a crash in the SFTP server. While the flaw does not enable memory corruption or code execution, it can disrupt availability for legitimate users.

No Red Hat products or offerings are affected by this vulnerability.

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.
Phonenumbers improper input validation
CVE: CVE-2025-10954
Component: github.com/nyaruka/phonenumbers
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-09-27T05:00:00.966000+00:00

Versions of the package github.com/nyaruka/phonenumbers before 1.2.2 are vulnerable to Improper Validation of Syntactic Correctness of Input in the phonenumbers.Parse() function. An attacker can cause a panic by providing crafted input causing a "runtime error: slice bounds out of range".

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.
PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV
CVE: CVE-2025-40219
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-04T00:00:00+00:00

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

PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV

Before disabling SR-IOV via config space accesses to the parent PF,
sriov_disable() first removes the PCI devices representing the VFs.

Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")
such removal operations are serialized against concurrent remove and
rescan using the pci_rescan_remove_lock. No such locking was ever added
in sriov_disable() however. In particular when commit 18f9e9d150fc
("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device
removal into sriov_del_vfs() there was still no locking around the
pci_iov_remove_virtfn() calls.

On s390 the lack of serialization in sriov_disable() may cause double
remove and list corruption with the below (amended) trace being observed:

  PSW:  0704c00180000000 0000000c914e4b38 (klist_put+56)
  GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001
	00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480
	0000000000000001 0000000000000000 0000000000000000 0000000180692828
	00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8
  #0 [3800313fb20] device_del at c9158ad5c
  #1 [3800313fb88] pci_remove_bus_device at c915105ba
  #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198
  #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0
  #4 [3800313fc60] zpci_bus_remove_device at c90fb6104
  #5 [3800313fca0] __zpci_event_availability at c90fb3dca
  #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2
  #7 [3800313fd60] crw_collect_info at c91905822
  #8 [3800313fe10] kthread at c90feb390
  #9 [3800313fe68] __ret_from_fork at c90f6aa64
  #10 [3800313fe98] ret_from_fork at c9194f3f2.

This is because in addition to sriov_disable() removing the VFs, the
platform also generates hot-unplug events for the VFs. This being the
reverse operation to the hotplug events generated by sriov_enable() and
handled via pdev->no_vf_scan. And while the event processing takes
pci_rescan_remove_lock and checks whether the struct pci_dev still exists,
the lack of synchronization makes this checking racy.

Other races may also be possible of course though given that this lack of
locking persisted so long observable races seem very rare. Even on s390 the
list corruption was only observed with certain devices since the platform
events are only triggered by config accesses after the removal, so as long
as the removal finished synchronously they would not race. Either way the
locking is missing so fix this by adding it to the sriov_del_vfs() helper.

Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()
including for the error case where pci_stop_and_remove_bus_device() is
called without the PCI rescan-remove lock being held. Even in the non-error
case, adding new PCI devices and buses should be serialized via the PCI
rescan-remove lock. Add the necessary locking.


Remediation:
via_wdt: fix critical boot hang due to unnamed resource allocation
CVE: CVE-2025-71114
Component: kernel
CWE: CWE-909
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-01T00:00:00+00:00

A boot hang vulnerability was found in the Linux kernel's VIA watchdog timer driver. When allocating a MMIO resource for the watchdog control register, the driver fails to assign a name to the resource. This creates an invalid "<BAD>" entry in the kernel resource tree under /proc/iomem, which can cause subsequent resource lookups and conflict checks to fail, leading to a system hang during boot.

Statement: This vulnerability affects systems with VIA chipsets that use the via_wdt watchdog driver. The boot hang occurs during early system initialization when the unnamed resource causes resource management failures. Systems without VIA hardware or with the via_wdt module not loaded are not affected.

Remediation:
To mitigate this issue, prevent the via_wdt module from being loaded if VIA watchdog timer functionality is not required. See https://access.redhat.com/solutions/41278 for instructions on how to blacklist a kernel module.
comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()
CVE: CVE-2025-68335
Component: kernel
Severity: None
Release date: 2025-12-22T00:00:00+00:00

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

comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()

Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from
the fact that in case of early device detach via pcl818_detach(),
subdevice dev->read_subdev may not have initialized its pointer to
&struct comedi_async as intended. Thus, any such dereferencing of
&s->async->cmd will lead to general protection fault and kernel crash.

Mitigate this problem by removing a call to pcl818_ai_cancel() from
pcl818_detach() altogether. This way, if the subdevice setups its
support for async commands, everything async-related will be
handled via subdevice's own ->cancel() function in
comedi_device_detach_locked() even before pcl818_detach(). If no
support for asynchronous commands is provided, there is no need
to cancel anything either.

[1] Syzbot crash:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762
...
Call Trace:
 <TASK>
 pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115
 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207
 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]
 comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
...


Remediation:
md: fix mddev uaf while iterating all_mddevs list
CVE: CVE-2025-22126
Component: kernel
CWE: CWE-416
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-04-16T00:00:00+00:00

A flaw was discovered in the Linux kernel’s MD (multiple device) subsystem during iteration over the all_mddevs list in functions such as md_notify_reboot() and md_exit(). The code used list_for_each_entry_safe, but released locks before completing reference counting, allowing concurrent deletion and freeing of an mddev entry. This led to a use-after-free when the kernel continued to reference freed mddev structures. A local user with low privileges could trigger this to corrupt memory and cause a denial of service. The issue has been resolved by reworking the iteration logic, introducing proper locking and reference handling (mddev_put_locked()), and switching to list_for_each_entry to avoid unsafe continuation across deletions


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.
mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()
CVE: CVE-2025-68765
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

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

mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()

In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the
subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function
returns an error without freeing sskb, leading to a memory leak.

Fix this by calling dev_kfree_skb() on sskb in the error handling path
to ensure it is properly released.


Remediation:
iwlwifi: Add missing check for alloc_ordered_workqueue
CVE: CVE-2025-38602
Component: kernel
CWE: CWE-252
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-08-19T00:00:00+00:00

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

iwlwifi: Add missing check for alloc_ordered_workqueue

Add check for the return value of alloc_ordered_workqueue since it may
return NULL pointer.

Statement: In iwlwifi (DVM), the return value of alloc_ordered_workqueue() wasn’t checked; under memory pressure it can return NULL, and subsequent use causes a kernel NULL dereference during driver init. Exploitation requires the driver to be loaded (typically root/boot-time), so this is a local DoS.

Remediation:
To mitigate this issue, prevent modules iwlcore, iwlwifi from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()
CVE: CVE-2025-39910
Component: kernel
CWE: CWE-833
Severity: Moderate
CVSS v3: 6.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-10-01T00:00:00+00:00

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

mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()

kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and
always allocate memory using the hardcoded GFP_KERNEL flag.  This makes
them inconsistent with vmalloc(), which was recently extended to support
GFP_NOFS and GFP_NOIO allocations.

Page table allocations performed during shadow population also ignore the
external gfp_mask.  To preserve the intended semantics of GFP_NOFS and
GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate
memalloc scope.

xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.

There was a report here
https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com

This patch:
 - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;
 - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();
 - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()
   around apply_to_page_range();
 - Updates vmalloc.c and percpu allocator call sites accordingly.

Statement: KASAN’s vmalloc shadow population ignored the caller’s gfp_mask, allocating with GFP_KERNEL even in GFP_NOFS/NOIO contexts. This could trigger filesystem/block reclaim and re-entrancy, leading to deadlocks under load (e.g., XFS calling vmalloc(GFP_NOFS)).

Remediation:
privilege escalation via use-after-free
CVE: CVE-2025-30232
Component: exim
CVSS v3: 8.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Release date: 2025-03-27T00:00:00+00:00

A use-after-free in Exim 4.96 through 4.98.1 could allow users (with command-line access) to escalate privileges.

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: