huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
accel/qaic: Fix bootlog initialization ordering
CVE: CVE-2025-40177
Component: kernel
Severity: None
Release date: 2025-11-12T00:00:00+00:00

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

accel/qaic: Fix bootlog initialization ordering

As soon as we queue MHI buffers to receive the bootlog from the device,
we could be receiving data. Therefore all the resources needed to
process that data need to be setup prior to queuing the buffers.

We currently initialize some of the resources after queuing the buffers
which creates a race between the probe() and any data that comes back
from the device. If the uninitialized resources are accessed, we could
see page faults.

Fix the init ordering to close the race.


Remediation:
fastify-reply-from: Unauthorized route access via malicious URL
CVE: CVE-2025-66415
Component: fastify-reply-from
CWE: CWE-441
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Release date: 2025-12-01T22:39:32.468000+00:00

A flaw was found in fastify-reply-from. This vulnerability allows an attacker to bypass intended route restrictions and gain unauthorized access to specific application routes, potentially exposing sensitive information or functionality, via crafting a malicious Uniform Resource Locator (URL).

Statement: This vulnerability is rated Moderate for Red Hat because it allows an attacker to bypass intended route restrictions in applications utilizing the `fastify-reply-from` plugin by crafting a malicious URL. This could lead to unauthorized access to specific application routes, potentially exposing sensitive information or functionality.

Remediation:
To mitigate the risk associated with this vulnerability, Red Hat recommends restricting network access to applications utilizing `fastify-reply-from` to trusted networks only. Additionally, ensure that any routes intended to be inaccessible via forwarding have robust, independent access control mechanisms in place, separate from the `fastify-reply-from` plugin's internal logic. If the `fastify-reply-from` functionality is not essential, consider disabling or removing the plugin to eliminate the attack surface.
wifi: mac80211: increase scan_ies_len for S1G
CVE: CVE-2025-39957
Component: kernel
Severity: Low
CVSS v3: 4.5/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-10-09T00:00:00+00:00

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

wifi: mac80211: increase scan_ies_len for S1G

Currently the S1G capability element is not taken into account
for the scan_ies_len, which leads to a buffer length validation
failure in ieee80211_prep_hw_scan() and subsequent WARN in
__ieee80211_start_scan(). This prevents hw scanning from functioning.
To fix ensure we accommodate for the S1G capability length.

Statement: ieee80211_prep_hw_scan() computed scan_ies_len without including the S1G capability element. The mismatch tripped a length check and triggered a WARN in __ieee80211_start_scan(), effectively disabling hardware scans until corrected. The change increases scan_ies_len to accommodate S1G.

Remediation:
To mitigate this issue, prevent module mac80211 from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
net/mlx5: Check device memory pointer before usage
CVE: CVE-2025-38645
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.0/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-08-22T00:00:00+00:00

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

net/mlx5: Check device memory pointer before usage

Add a NULL check before accessing device memory to prevent a crash if
dev->dm allocation in mlx5_init_once() fails.

Statement: A flaw in the Mellanox mlx5 device memory handling could cause a NULL pointer dereference when the driver attempts to access uninitialized device memory. If mlx5_dm_create() fails and returns NULL, later code may still try to use the pointer, resulting in a kernel crash. This makes it possible for a local user interacting with the hardware to trigger a denial of service, though it does not expose data or allow privilege escalation.

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.
Improper handling of headers in `Rack::Sendfile` may allow proxy bypass
CVE: CVE-2025-61780
Component: rubygem-rack
CWE: CWE-444
Severity: Moderate
CVSS v3: 5.7/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Release date: 2025-10-10T16:53:57.606000+00:00

A potential information disclosure vulnerability has been identified in the RubyGem Rack affecting Rack::Sendfile when used behind a proxy that supports x-sendfile headers (e.g., Nginx). When processing untrusted x-sendfile-type or x-accel-mapping headers, the middleware could misinterpret them as proxy directives, causing the proxy to make unintended internal requests. An attacker could exploit this by sending crafted headers and requesting paths that trigger proxy-based acceleration, potentially accessing internal application endpoints that are normally protected. The issue does not allow arbitrary file reads, code execution, or denial of service.

Statement: This vulnerability is classified as Moderate severity primarily because exploitation requires a specific deployment scenario meeting all of the following conditions: 

- The application must use Rack::Sendfile behind a proxy that supports x-accel-redirect (eg. Nginx) 

- The proxy must not consistently set or remove the relevant x-sendfile-type and x-accel-mapping headers
 
- The application must expose endpoints returning objects responding to .to_path. 

Exploitation could allow attackers to bypass proxy-enforced access controls and reach internal routes.

~~~

CVSS Assessment:

Scope (S:C): Changed — the attack affects the proxy's interpretation of internal routes, which is outside the original application scope.

Confidentiality (C:L): Low — attacker can only see internal endpoints, but does not allow arbitrary file access or sensitive data exposure.

~~~

~~~

Affectedness:

Ruby 2.x and 3.x versions shipped with Red Hat Enterprise Linux, Red Hat Openshift Core OS (RHOCS) and Red Hat In-Vehicle OS (RHIVOS) are not affected, as they do not bundle the rack RubyGem by default. Rack is a third-party gem that must be installed separately.

~~~

Remediation:
No mitigation is currently available that meets Red Hat Product Security's standards for usability, deployment, applicability, or stability.
fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var
CVE: CVE-2025-38215
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-07-04T00:00:00+00:00

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

fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var

If fb_add_videomode() in do_register_framebuffer() fails to allocate
memory for fb_videomode, it will later lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.

================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
 display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
 resize_screen drivers/tty/vt/vt.c:1176 [inline]
 vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================

Even though fbcon_init() checks beforehand if fb_match_mode() in
var_to_display() fails, it can not prevent the panic because fbcon_init()
does not return error code. Considering this and the comment in the code
about fb_match_mode() returning NULL - "This should not happen" - it is
better to prevent registering the fb_info if its mode was not set
successfully. Also move fb_add_videomode() closer to the beginning of
do_register_framebuffer() to avoid having to do the cleanup on fail.

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


Remediation:
sctp: initialize more fields in sctp_v6_from_sk()
CVE: CVE-2025-39812
Component: kernel
Severity: None
Release date: 2025-09-16T00:00:00+00:00

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

sctp: initialize more fields in sctp_v6_from_sk()

syzbot found that sin6_scope_id was not properly initialized,
leading to undefined behavior.

Clear sin6_scope_id and sin6_flowinfo.

BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983
  sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390
  sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452
  sctp_get_port net/sctp/socket.c:8523 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
  x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Local variable addr.i.i created at:
  sctp_get_port net/sctp/socket.c:8515 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930


Remediation:
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
CVE: CVE-2025-38700
Component: kernel
CWE: CWE-825
Severity: Moderate
CVSS v3: 5.4/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
Release date: 2025-09-04T00:00:00+00:00

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

scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated

In case of an ib_fast_reg_mr allocation failure during iSER setup, the
machine hits a panic because iscsi_conn->dd_data is initialized
unconditionally, even when no memory is allocated (dd_size == 0).  This
leads invalid pointer dereference during connection teardown.

Fix by setting iscsi_conn->dd_data only if memory is actually allocated.

Panic trace:
------------
 iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
 BUG: unable to handle page fault for address: fffffffffffffff8
 RIP: 0010:swake_up_locked.part.5+0xa/0x40
 Call Trace:
  complete+0x31/0x40
  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]
  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]
  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]
  ? netlink_lookup+0x12f/0x1b0
  ? netlink_deliver_tap+0x2c/0x200
  netlink_unicast+0x1ab/0x280
  netlink_sendmsg+0x257/0x4f0
  ? _copy_from_user+0x29/0x60
  sock_sendmsg+0x5f/0x70


Remediation:
PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release
CVE: CVE-2025-40032
Component: kernel
Severity: None
Release date: 2025-10-28T00:00:00+00:00

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

PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release

The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be
NULL even after EPF initialization. Then it is prudent to check that
they have non-NULL values before releasing the channels. Add the checks
in pci_epf_test_clean_dma_chan().

Without the checks, NULL pointer dereferences happen and they can lead
to a kernel panic in some cases:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
  Call trace:
   dma_release_channel+0x2c/0x120 (P)
   pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]
   pci_epc_deinit_notify+0x74/0xc0
   tegra_pcie_ep_pex_rst_irq+0x250/0x5d8
   irq_thread_fn+0x34/0xb8
   irq_thread+0x18c/0x2e8
   kthread+0x14c/0x210
   ret_from_fork+0x10/0x20

[mani: trimmed the stack trace]


Remediation:
MySQL Server: Denial of service in Thread Pooling component
CVE: CVE-2025-21521
Component: mysql
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-01-21T20:53:04.705000+00:00

A flaw was found in MySQL Server (Thread Pooling component). This vulnerability allows a denial of service (DoS) via network access through multiple protocols by an unauthenticated attacker.


Remediation:
ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()
CVE: CVE-2025-40198
Component: kernel
CWE: CWE-170
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-11-12T00:00:00+00:00

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

ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()

Unlike other strings in the ext4 superblock, we rely on tune2fs to
make sure s_mount_opts is NUL terminated.  Harden
parse_apply_sb_mount_options() by treating s_mount_opts as a potential
__nonstring.

Statement: The s_mount_opts field in ext4 superblocks is parsed at mount time, with the kernel relying on tune2fs to ensure NUL termination. If a malicious image lacks proper termination, parse_apply_sb_mount_options walks past the field boundary searching for the NUL byte, potentially reading adjacent superblock fields or unmapped memory. The fix treats s_mount_opts as potentially unterminated and adds explicit bounds checking during parsing.

Remediation:
.NET Remote Code Execution Vulnerability
CVE: CVE-2025-21171
Component: dotnet
CWE: CWE-122
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-01-14T18:03:22.942000+00:00

A remote code execution vulnerability was found in .NET. This flaw allows an attacker to load a specially crafted file into a vulnerable application.

Statement: This issue affects .NET Framework version 9.0 as shipped with all versions of RHEL. However, this flaw is not known to be exploitable under any supported scenario.

```

.NET 6.0 for RHEL-8, RHEL-9 and RHIVOS has reached its End of Life as of November 12, 2024, and is no longer supported. For additional information about lifecycle for .NET on Red Hat Enterprise Linux, please refer to: https://access.redhat.com/support/policy/updates/net-core.

```

Remediation:
Red Hat has investigated whether a possible mitigation exists for this issue, and has not been able to identify a practical example. Please update the affected package as soon as possible.
efi: Don't map the entire mokvar table to determine its size
CVE: CVE-2025-21872
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-03-27T00:00:00+00:00

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

efi: Don't map the entire mokvar table to determine its size

Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   <TASK>
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   </TASK>
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.

Mapping the entire structure isn't actually necessary, as we don't ever
need more than one entry header mapped at once.

Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we're not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than attempting to
verify it in place.


Remediation:
Frontend DoS vulnerability due to asymmetric resource consumption
CVE: CVE-2025-49643
Component: zabbix
CVSS v3: 6.4/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-12-01T13:05:33.613000+00:00

An authenticated Zabbix user (including Guest) is able to cause disproportionate CPU load on the webserver by sending specially crafted parameters to /imgstore.php, leading to potential denial of service.

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:
OpenBao leaks HTTPRawBody in Audit Logs
CVE: CVE-2025-62513
Component: github.com/openbao/openbao/audit
CVSS v3: 5.3/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N
Release date: 2025-10-22T19:18:59.643000+00:00

OpenBao is an open source identity-based secrets management system. In versions 2.2.0 to 2.4.1, OpenBao's audit log experienced a regression wherein raw HTTP bodies used by few endpoints were not correctly redacted (HMAC'd). This impacts those using the ACME functionality of PKI, resulting in short-lived ACME verification challenge codes being leaked in the audit logs. Additionally, this impacts those using the OIDC issuer functionality of the identity subsystem, auth and token response codes along with claims could be leaked in the audit logs. ACME verification codes are not usable after verification or challenge expiry so are of limited long-term use. This issue has been patched in OpenBao 2.4.2.

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.
CVE: CVE-2025-0899
Component: PDF-XChange Editor AcroForm Use-After-Free Remote Code Execution Vulnerability
Release date: 2025-01-31T22:06:12.503000+00:00

PDF-XChange Editor AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of PDF-XChange Editor. 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 handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-25349.

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:
block: avoid possible overflow for chunk_sectors check in blk_stack_limits()
CVE: CVE-2025-39795
Component: kernel
CWE: CWE-190
Severity: Low
CVSS v3: 4.0/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L
Release date: 2025-09-12T00:00:00+00:00

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

block: avoid possible overflow for chunk_sectors check in blk_stack_limits()

In blk_stack_limits(), we check that the t->chunk_sectors value is a
multiple of the t->physical_block_size value.

However, by finding the chunk_sectors value in bytes, we may overflow
the unsigned int which holds chunk_sectors, so change the check to be
based on sectors.

Statement: This vulnerability is rated Low for Red Hat Enterprise Linux because a possible integer overflow in the `blk_stack_limits()` function within the kernel's block layer could be exploited by an attacker with high privileges. Successful exploitation may lead to a denial of service or information disclosure. Triggering this vulnerability requires elevated privileges (ex. `CAP_SYS_ADMIN`) as modifying or creating block stacks is a privileged operation. If the bug is triggered, then there are potentially impacts to integrity and availability, in that a misalignment could result in an incorrect write to storage which in turn could cause some I/O errors, though they are unlikely to hang the system outright. 

This affects Red Hat Enterprise Linux 7, 8, 9, 10, and Red Hat In-Vehicle OS.

Remediation:
spufs: fix a leak on spufs_new_file() failure
CVE: CVE-2025-22073
Component: kernel
Severity: None
Release date: 2025-04-16T00:00:00+00:00

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

spufs: fix a leak on spufs_new_file() failure

It's called from spufs_fill_dir(), and caller of that will do
spufs_rmdir() in case of failure.  That does remove everything
we'd managed to create, but... the problem dentry is still
negative.  IOW, it needs to be explicitly dropped.


Remediation:
Apache Parquet Java: Potential malicious code execution from trusted packages in the parquet-avro module when reading an Avro schema from a Parquet file metadata
CVE: CVE-2025-46762
Component: org.apache.parquet/parquet-avro
CWE: CWE-73
Severity: Important
CVSS v3: 8.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-05-06T09:08:13.996000+00:00

A flaw was found in the Apache Parquet parquet-avro module. This vulnerability allows potential malicious code execution via malicious schema deserialization when using the "specific" or "reflect" Avro data models to read Parquet files. Simply opening or processing a Parquet file could potentially compromise the integrity of the system.


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.