HCP S11 and S31 Node 3.2.0 Release Notes

Apple macOS

Linux

Microsoft Windows

Apple macOS

Linux

Microsoft Windows

A vulnerability exists in the Debian initrd script for the cryptsetup package 2:1.7.3-2 and earlier that lets attackers who are physically nearby gain shell access by means of multiple login attempts with an invalid password.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2016-4484.

A vulnerability exists in the Tomcat package on Red Hat Enterprise Linux (RHEL) 7, Fedora, CentOS, Oracle Linux, and possibly other Linux distributions wherein users in the tomcat group can modify the /usr/lib/tmpfiles.d/tomcat.conf configuration file. The weak permissions for the group enable members of the group to escalate their privileges, even to the point of giving themselves root privileges.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2016-5425.

In PyYAML versions earlier than 5.1, a remote attacker can use the load() function to execute arbitrary code.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2017-18342.

While the Linux kernel is handling TCP Selective Acknowledgments (SACKs), the TCP_SKB_CB(skb)->tcp_gso_segs value is subject to an integer overflow. A remote attacker can take advantage of this flaw to cause a denial of service.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2019-11477.

FasterXML jackson-databind 2.x versions earlier than 2.9.9.1 incorrectly handle deserialization for a particular class. Depending on the classpath content, a remote attacker can take advantage of this flaw to execute malicious code.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2019-12384.

When Apache Tomcat 9.0.0.M1 to 9.0.28, 8.5.0 to 8.5.47, 7.0.0, or 7.0.97 is configured with the JMX Remote Lifecycle Listener enabled, a local attacker without access to the Tomcat process or configuration files can manipulate the RMI registry to perform a man-in-the-middle attack. The attacker can then get usernames and passwords used to access the JMX interface, enabling the attacker to gain complete control over the Tomcat instance.

For more information about this CVE, see https://access.redhat.com/security/cve/cve-2019-12418.

Multiple functions in ipmitool versions earlier than 1.8.19 do not properly check data received from a remote LAN party. This flaw enables a remote authenticated attacker to overflow a buffer and execute malicious code on the ipmitool host. This vulnerability is increased if ipmitool is run as a privileged user.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-5208.

The VFIO PCI driver in versions 5.6.13 and earlier of the Linux kernel mishandles attempts to access disabled memory space. When a guest user or process tries to access disabled memory space, a fatal error condition may occur, causing the host system to crash. This crash results in a denial of service.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-12888.

PostgreSQL JDBC versions earlier than 42.2.13 have an XML External Entity (XXE) weakness wherein a local or remote attacker can cause PostgreSQL to embed malicious documents into output. This vulnerability is a threat to data confidentiality and system availability.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-13692.

GnuTLS versions starting from 3.6.4 and earlier than 3.6.14 have a flaw wherein incorrect cryptography is used for encrypting session tickets. Until the first key rotation, the TLS server always uses wrong data in place of an encryption key derived from an application. With TLS 1.3, the incorrect key provides the ability to bypass authentication, enabling an attacker to craft a man-in-the-middle attack. With TLS 1.2, the incorrect key enables an attacker to recover old conversations, posing a threat to data confidentiality.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-13777.

PyYAML library versions earlier than 5.4 is susceptible to arbitrary code execution when untrusted YAML files are processed through the full_load method or with the FullLoader loader. This flaw allows an attacker to execute arbitrary code on the system by using the python/object/new constructor.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-14343.

Apache Struts versions 2.0.0 through 2.5.25 have a vulnerability that enables attackers to perform remote code execution. This vulnerability occurs when Apache Struts framework is forced to perform double evaluation of attributes. Double evaluation is when an expression string gets evaluated as code, and then, if the result is another string, that string gets evaluated as code, too. Attackers can execute system commands by sending specially crafted HTTP requests containing malicious payloads for double evaluation to the target server.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2020-17530.

In sudo versions earlier than 1.9.5p2, a heap-based buffer overflow was found in the way sudo parses command-line arguments. This flaw enables unprivileged local users to escalate their own privileges to root on the host system. With root privileges, users can execute code that compromises data confidentiality and integrity or causes system unavailability.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-3156.

OpenSSL is vulnerable to a buffer overflow caused by improper bounds checking by the EVP_PKEY_decrypt() function used for SM2 decryption. A remote attacker can present SM2 content to an application for decryption, where that content overflows the buffer, possibly changing application behavior or causing the application to crash. This flaw compromises data confidentiality and integrity and can result in system unavailability.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-3711.

With OpenSSL, an ASN.1 string that is not NUL terminated can cause a read buffer overflow. A remote attacker can take advantage of this flaw by forcing an application to call the openssl function with a string that is not NUL terminated. This flaw enables the disclosure of private memory and can cause the application to crash.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-3712.

With some Intel Trace Hub instances, when the hardware allows activation of the test or debug logic at runtime, a malicious attacker with physical access to the hardware can bypass security restrictions and, thereby, escalate privileges on the targeted system.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-33150.

A missing HTTP (X-Frame-Options) header in Kiwi Syslog Server enables malicious attackers to perform clickjacking attacks. An attacker can use a transparent iframe in a window to trick users into clicking an actionable item that links to an identical web page on another server.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-35237.

HCP S11 and S31 Nodes were not and are not vulnerable to CVE-2021-35515. However, the SevenZ library has been updated to prevent security scans from flagging the library for this CVE.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-35515.

Apache Tomcat versions 10.1.0 through 10.1.0-M12, 10.0.0-M1 through 10.0.18, 9.0.0-M1 through 9.0.60, and 8.5.0 through 8.5.77 have a concurrency bug that can cause client connections to share an Http11Processor instance, resulting in responses or partial responses being received by the wrong client. This misdirection compromises data security.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-43980.

With Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4), an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender. The JDBC Appender can be modified with a data source referencing a JNDI URI that can execute remote code.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2021-44832.

In some Intel Processors, nontransparent sharing of branch predictor selectors between contexts may enable local authorized users to enable information disclosure.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-0001.

In some Intel Processors, nontransparent sharing of a branch predictor within a context may enable local authorized users to enable information disclosure.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-0002.

The Apache Tomcat version 10.1.0-M1 through 10.1.0-M14, 10.0.0-M1 through 10.0.20, 9.0.13 through 9.0.62, and 8.5.38 through 8.5.78 documentation for the EncryptInterceptor incorrectly states that EncryptInterceptor enables Tomcat clustering to run over an untrusted network. This is not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly denial-of-service risks.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-29885.

The PostgreSQL JDBC Driver (PgJDBC) implementation of the `java.sql.ResultRow.refreshRow()` method is not performing escaping of column names. A malicious column name that contains a statement terminator can lead to SQL injection, resulting in the execution of additional SQL commands as the application's JDBC user.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-31197.

FasterXML/woodstox is an XML processor that parses XML data. If DTD support is enabled and if the parser is running on user-supplied input, an attacker can supply malicious content that results in a stack overflow, thereby causing the parser to crash. This effect can amount to a denial-of-service attack.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-40152.

HCP S11 and S31 Nodes were not and are not vulnerable to CVE-2022-40982. Because S11 and S31 Nodes are closed appliances running only the HCP S Series software, the Intel CPU downfall vulnerability cannot be exploited against them.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-40982.

With the XML.toJSONObject component of hutool-json version 5.8.10, a malicious attacker can cause a crash by sending specially crafted JSON or XML data that triggers a stack overflow, resulting in a denial of service.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2022-45688.

In sudo versions 1.8.0 through 1.9.12.p1, the sudoedit (also known as -e) feature mishandles extra arguments passed in the user-provided SUDO_EDITOR, VISUAL, and EDITOR environment variables, allowing a local attacker to append arbitrary entries to the list of files to process. Editing an arbitrary file with the privileges of the RunAs user can lead to privilege escalation.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2023-22809.

With cURL versions 7.69.0 through 8.3.0, if the hostname presented to cURL is longer than 255 bytes, cURL switches to local name resolution and passes only the resolved address to the SOCKS5 proxy. If the SOCKS5 handshake is slow, the too-long hostname instead of the resolved address can end up being copied to the target heap-based buffer, resulting in a buffer overflow.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2023-38545.

Libcurl versions 7.9.1 through 8.3.0 contain a flaw that allows an attacker to insert cookies into a running program at will. An application can create an individual handle for a single transfer and then use libcurl to duplicate that handle. If a transfer has cookies enabled when the handle is duplicated, the cookie-enable state is also cloned, but the cookies themselves are not. If the source handle doesn't read any cookies from a specific file, the cloned handle stores the file with a default name. When used again, the cloned handle loads cookies, if any, from the file with the default name, in which an attacker can have stored malicious user-supplied cookies.

For more information about this CVE, see https://nvd.nist.gov/vuln/detail/CVE-2023-38546.

When an enclosure powers back on after losing power, the S Series Node falsely reports that the fan hardware is unsupported for each rear fan and each controller-bay fan. Messages about the unsupported hardware are written to the event log, and alerts reporting the unsupported hardware are briefly in effect. The part number shown for each fan in the full message text is NO_PSN_PRE. Despite the reports, the fan hardware is still supported, and the fans are operating correctly.

Fix: An enclosure powering back on after losing power no longer causes the S Series Node to report that the fan hardware is unsupported.

After a fresh installation or reinstallation of the HCP S Series software, the first time you try to generate your access and secret keys for the S3 compatible API in the HCP S Series Management Console, the Next button may be inactive, with the Finish button active. If you select Yes to generate the keys and then click Finish, the generated keys are not displayed. In subsequent attempts to generate the keys, the Next button is active. If you select Yes and then click Next, the keys are displayed.

Fix: With the new Management Console, this issue no longer happens.

If you configure secondary IPv6 addressing for the S Series Node access network while syslog logging is enabled, the secondary virtual IPv6 addresses are not enabled and cannot be used for access to the S Series Node.

Fix: Now, when you configure IPv6 addressing for the S Series Node access network while syslog logging is enabled, the secondary virtual IPv6 addresses are enabled and can be used for access to the S Series Node.

Rarely, when you apply an SSL server certificate that has been signed by a certificate authority (CA), the S Series Node cannot upload the certificate.

Fix: The S Series Node now consistently uploads certificates that have been signed by a CA.

When you click the Legend button below the diagram on the server module details page, the legend window does not open.

Fix: With the new Management Console, this issue no longer happens.

When you specify DNS servers or time servers, you select the network (access or management) to be used for communication with those servers. If the selected network is configured for IPv6 and has a secondary IPv6 gateway configured, you can choose to use either the primary or secondary IPv6 gateway with the DNS servers or time servers.

With the HCP S Series management API, the IPv6 gateway option is specified by the networkIndex property of the /‍configuration/dns or /‍configuration/time resource, as applicable. A value of 1 means use the primary IPv6 gateway. A value of 2 means use the secondary IPv6 gateway.

If the value of the networkIndex property for the /‍configuration/dns or /‍configuration/time resource is 2 and you delete the secondary IPv6 gateway configuration from the selected network, the value of the networkIndex property remains 2, even though no secondary IPv6 gateway exists. In spite of this incorrect value, the S Series Node correctly switches to using the primary IPv6 gateway.

Fix: When you delete the secondary IPv6 gateway configuration from the network selected for the DNS servers of time servers, the value of the networkIndex property for the management API /‍configuration/dns or /‍configuration/time resource, as applicable, automatically changes to 1.

The process used by the S Series Node to generate a self-signed SSL server certificate contains an error.

Fix: The process used by the S Series Node to generate a self-signed certificate has been corrected.

To display the legend for a server module on the Hardware Overview page in the HCP S Series Management Console, you click the gear icon () for the server module and then click Legend. After you open the legend for one server module, when you perform these steps for the other server module, the legend does not open.

Fix: With the new Management Console, this issue no longer happens.

When storage becomes 70% or 95% full, a message is written to the event log, and an alert is issued. In each case, the message and alert have a severity level of NOTICE, which causes the HCP S Series Management Console to use green for the alert display.

Fix: Event messages and alerts now occur when storage becomes 70%, 85%, or 95% full. For 70% or 85% full, the message and alert have a severity level of WARNING, and the Management Console uses orange for the alert display. For 95% full, the message and alert have a severity level of ERROR, and the Management Console uses red for the alert display.

The alert that indicates that a database drive is degraded or being resynced or recovered should appear on the details page for the enclosure. Instead, the alert appears on the details page for the applicable server module. Additionally in this case, on the details page for the applicable slot, the row that shows the status of the database partition is not highlighted in red.

If beaconing is on for an enclosure or for a component in an enclosure at 1:00 a.m. on a Sunday, for a brief period after that time, the event log may contain messages indicating that beaconing was turned off and back on a few times. At the end of this period, beaconing remains on.

Rarely, while one server module is rebooting, the S Series Node incorrectly reports that the other server module is unavailable. A message about the unavailability is written to the event log, and an alert reporting the unavailability is briefly in effect (no more than a few seconds). Despite the report, the server module did not, in fact, become unavailable.

After you change the MTU to 9,000 for the access or management network, the S Series Node falsely reports that a network interface is not operating at the correct MTU. A message about the incorrect operation is written to the event log, and an alert reporting the incorrect operation is briefly in effect (no more than two minutes). Despite the report, the network interface is operating at the correct MTU.

If, before the S Series Node is upgraded to release 3.2.0, the access network is configured for IPv6 and is selected for the DNS or time servers, but the DNS or time servers are specified by IPv4 addresses, the HCP S Series Management Console correctly displays error messages indicating that the S Series Node cannot reach the DNS or time servers, as applicable. When the S Series Node is upgraded to release 3.2.0, the network and DNS and time server settings do not change. However, if the management network is configured for IPv4, the S Series Node uses the management network to reach the DNS or time servers, as applicable, and does not display any error messages. If the management network is configured for IPv6, the S Series Node still cannot reach the DNS or time servers and displays the applicable error messages.

While the access network IP mode is IPv6, if the deny list for access to the HCP S Series Management Console contains both IPv4 and IPv6 addresses, those addresses are not denied access to the Console on the access network.

With the access network and management network both configured for IPv4 and the management network selected for communication with DNS servers or time servers, if you change the IP mode of the access network to IPv6, the S Series Node can no longer communicate with the DNS servers or time servers, as applicable, on the management network. To re-enable communication with the DNS servers or time servers on the management network, use the HCP S Series Management Console or management API to reboot the S Series Node.

When you enable management network monitoring while the management port is connected to an active network, the S Series Node falsely reports that the eth4 network interface is down. A message about the condition is written to the event log, and an alert reporting the condition is in effect. Despite the report, the network interface is connected and operating correctly.

On the details page for the access network, the Duplex, Bonding Mode, and MTU fields are grayed, making those fields appear to be inactive. Similarly, on the details page for the management network, the MTU field is grayed, making that field appear to be inactive. In fact, these fields are active, and you can select values in them.

If you try to add an S Series Node to a release 7.x HCP system, where the minimum TLS version on the S Series Node is higher than 1.0, an error occurs on the HCP system. The error message displayed in the HCP System Management Console is peer is not authenticated. This message is also displayed for other types of errors. If you see this message, check the minimum TLS version setting on the S Series Node. If the setting is 1.0, a different error has occurred.

For internal purposes, the S Series Node uses VLAN IDs of either 700 and 800 or 701 and 801. To determine which pair of VLAN IDs is being used internally, check the network interface name for the server interconnect network in the Network Interfaces section on the server module details page in the HCP S Series Management Console. If the name is eth4.800, VLAN IDs 700 and 800 are in use. If the name is eth4.801, VLAN IDs 701 and 801 are in use.

While the S Series Node is processing an HCP S Series management API request to update a network, a subsequent request to update the same network to its original settings has no effect.

The SAS cables for expansion enclosure 2 should be connected to rear ports 0 and 2 on the base enclosure. If these cables are connected to ports 1 and 3 instead, the diagram of the back of enclosure 2 in the HCP S Series Management Console incorrectly shows rear ports 1 and 3 as gray (not connected) and rear ports 0 and 2 as red (incorrectly connected).

The S Series Node supports a maximum of 10 syslog servers for syslog logging. However, on the SYSLOG page in the HCP S Series Management Console, the Add IP Address option remains active after 10 syslog servers have been added to the server list.

For an S11 or S31 Node that has more than one enclosure, disconnecting a SAS cable causes the server modules to see different sets of drives. As a result, the amount of available storage displayed on the HCP S Series Management Console DASHBOARD page or returned in response to a management API request for the /metrics/system resource differs depending on which server module provides the value.

On the enclosure details pages in the HCP S Series Management Console, the temperature readings and temperature thresholds are all -20C for components that are not present in the enclosure.

When you open the HCP S Series Management Console in Firefox on a Linux system that has a dark theme for buttons, the text boxes on the Console pages appear black. Text in the boxes is not visible unless it is highlighted. A similar problem occurs with certain menus in the Console. In those cases, the menu options are not visible unless they are highlighted.

This issue does not occur when the Linux system has a light theme for buttons.

After a drive is replaced, the top view of the applicable enclosure on the enclosure details page in the HCP S Series Management Console may show the new drive as unavailable, and the details window for the applicable slot may show the status for the new drive as Unavailable. Regardless of these status displays, if the Management Console does not show any alerts about the new drive, the drive is available and is functioning normally.

The amount of memory reported for an S Series Node in the HCP S Series Management Console or by the HCP S Series management API is slightly less than the expected amount of 64 GB for an S11 Node or the expected amount of 256 GB for an S31 Node.

Because the new HCP S Series Management Console uses the management API to communicate with the S Series Node, the management API must know about all the acceptable origins for requests from the Management Console. An origin is the fully qualified domain name of the S Series Node, the hostname of a server module in the S Series Node, or a physical or virtual IP address for a server module on the access or management network.

If you change an origin in any way (for example, add or change a virtual IP address or switch from IPv4 to IPv6 and update IP addresses accordingly), the management API does not know about the change until both server modules reboot. If the server modules have not rebooted yet, you cannot access the Management Console by entering the new origin in the browser address bar, and you cannot use the old origin because it is no longer valid.

If you change an origin for the management network or change the domain name of the S Series Node, the server modules automatically reboot. If you change an origin for the access network, you need to reboot the server modules yourself. So that the S Series Node remains available, reboot the server modules one at a time, waiting for the first one to become available before you reboot the second one.

The time servers for an S Series Node are identified by IP address. If the IP address of a time server changes such that the address no longer matches the IP address specified for that time server in the S Series Node, the S Series Node can no longer connect to that time server. This situation does not affect the operation of the S Series Node, even if that time server is the only time server specified for the S Series Node.

After an upgrade from a release earlier than 3.2.0 to release 3.2.0 or later, historical statistics for ingested data, object count, and the repair backlog that were available before the upgrade are no longer available. The earliest historical statistics for these items that can be displayed in the HCP S Series Management Console or returned by the management API start from the time the upgrade was complete.

An S Series Node can send event log messages, log messages for data access requests, and log messages for management API requests to specified syslog servers. Sending log messages for data access requests in particular can result in very heavy traffic to the syslog servers. Heavy syslog traffic can impede traffic on the server interconnect network, causing one server module to reboot.

In the HCP S Series Management Console and with the management API /metrics/system resource, the reported ideal amount of available storage is the amount of unused storage, not counting storage reserved for repair. If the amount of storage under repair is less than the amount of ideal available storage, the amount of available storage (actual) is reported as the amount of ideal available storage. In this case, the reported amount of available storage (actual) can be misleading because some of that storage may be used to complete the repair of any currently damaged storage and, therefore, may not be entirely available for storing and protecting new data.

Rarely, the HCP S Series Management Console unexpectedly logs out an active user with no warning. When this happens, the Management Console displays the login page, and the user can immediately log back in.

The S Series Node does not honor subnets in access control lists for the HCP S Series Management Console, management API, or S3 compatible API. You can add a subnet with the allow or deny option to an access control list, but doing so has no effect on whether IP addresses in the subnet can access the S Series Node through the applicable interface.

If you add an IP address for a syslog server on the SYSLOG page in the HCP S Series Management Console and then delete that IP address, you cannot add that IP address again.

Workaround: Reload the SYSLOG page. Then add the IP address again.

If the access control list for the HCP S Series Management Console has no IP addresses with the allow option and the "Allow access from IP address with both Allow and Deny settings" option is set to No, the Management Console is inaccessible. Similarly, if the access control list for the management API has no IP addresses with the allow option and the "Allow access from IP address with both Allow and Deny settings" option is set to No, the management API cannot be used to access the S Series Node. If access is blocked for both these interfaces, you cannot perform any management functions on the S Series Node.

The HCP S Series Node Help incorrectly states that, for password requirements, the default value is 1 for each character-set minimum. The correct value is 0 for each character set.