| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been identified in SIMATIC S7-300 CPU family (incl. related ET200 CPUs and SIPLUS variants) (All versions < V3.X.17), SIMATIC TDC CP51M1 (All versions < V1.1.8), SIMATIC TDC CPU555 (All versions < V1.1.1), SINUMERIK 840D sl (All versions < V4.8.6), SINUMERIK 840D sl (All versions < V4.94). Specially crafted packets sent to port 102/tcp (Profinet) could cause the affected device to go into defect mode. A restart is required in order to recover the system. Successful exploitation requires an attacker to have network access to port 102/tcp, with no authentication. No user interation is required. At the time of advisory publication no public exploitation of this security vulnerability was known. |
| A vulnerability has been identified in SIMATIC S7-300 CPUs (All versions < V3.X.16). The affected CPUs improperly validate S7 communication packets which could cause a Denial-of-Service condition of the CPU. The CPU will remain in DEFECT mode until manual restart. Successful exploitation requires an attacker to be able to send a specially crafted S7 communication packet to a communication interface of the CPU. This includes Ethernet, PROFIBUS, and Multi Point Interfaces (MPI). No user interaction or privileges are required to exploit the security vulnerability. The vulnerability could allow causing a Denial-of-Service condition of the core functionality of the CPU, compromising the availability of the system. At the time of advisory publication no public exploitation of this security vulnerability was known. Siemens confirms the security vulnerability and provides mitigations to resolve the security issue. |
| A vulnerability has been identified in SIMATIC S7-300 CPU family (All versions), SIMATIC S7-300 CPU family (incl. related ET200 CPUs and SIPLUS variants) (All versions), SIMATIC S7-400 PN/DP V6 and below CPU family (incl. SIPLUS variants) (All versions), SIMATIC S7-400 PN/DP V7 CPU family (incl. SIPLUS variants) (All versions), SIMATIC S7-400 V6 and earlier CPU family (All versions), SIMATIC S7-400 V7 CPU family (All versions). Specially crafted packets sent to port 80/tcp could cause the affected devices to go into defect mode. A cold restart is required to recover the system. |
| Siemens SIMATIC S7-300 CPU devices allow remote attackers to cause a denial of service (defect-mode transition) via crafted packets on (1) TCP port 102 or (2) Profibus. |
| In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation. |
| A vulnerability has been identified in RUGGEDCOM RST2428P (6GK6242-6PA00) (All versions < V4.0). The affected applications stores sensitive information in the browser cache when an authenticated user modify specific configurations. This could allow an authenticated attacker to access sensitive data stored in the browser. |
| An issue was discovered on Samsung Galaxy S3 i9305 4.4.4 devices. The WPA, WPA2, and WPA3 implementations reassemble fragments with non-consecutive packet numbers. An adversary can abuse this to exfiltrate selected fragments. This vulnerability is exploitable when another device sends fragmented frames and the WEP, CCMP, or GCMP data-confidentiality protocol is used. Note that WEP is vulnerable to this attack by design. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED)
ptr = &READ_ONCE(storage->buf)->data[0];
else
ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program's map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps. |
| Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4. |
| A vulnerability has been identified in blueplanet 100 NX3 M8 (All versions), blueplanet 100 TL3 GEN2 (All versions), blueplanet 105 TL3 (All versions), blueplanet 105 TL3 GEN2 (All versions), blueplanet 110 TL3 (All versions), blueplanet 125 NX3 M10 (All versions), blueplanet 125 TL3 (All versions), blueplanet 125 TL3 GEN2 (All versions), blueplanet 137 TL3 (All versions), blueplanet 150 TL3 (All versions), blueplanet 150 TL3 GEN2 (All versions), blueplanet 155 TL3 (All versions), blueplanet 155 TL3 GEN2 (All versions), blueplanet 165 TL3 (All versions), blueplanet 165 TL3 GEN2 (All versions), blueplanet 25.0 NX3-33.0 NX3 (All versions), blueplanet 3.0 NX3-20.0 NX3 (All versions), blueplanet 3.0-5.0 NX1 (All versions), blueplanet 360 NX3 M6 (All versions), blueplanet 50.0 NX3-60.0 NX3 (All versions), blueplanet 87.0 TL3 (All versions), blueplanet 87.0 TL3 GEN2 (All versions), blueplanet 92.0 TL3 (All versions), blueplanet 92.0 TL3 GEN2 (All versions), blueplanet gridsave 110 TL3-S (All versions), blueplanet gridsave 137 TL3-S (All versions), blueplanet gridsave 92.0 TL3-S (All versions), blueplanet hybrid 10.0 TL3 (All versions), blueplanet hybrid 6.0 NH3-12.0 NH3 (All versions). Improper neutralization of special elements used in an sql command ('sql injection') in KACO Meteor server allows an authorized attacker to elevate privileges over a local network. |
| The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w). |
| ABB, Phoenix Contact, Schneider Electric, Siemens, WAGO - Programmable Logic Controllers, multiple versions. Researchers have found some controllers are susceptible to a denial-of-service attack due to a flood of network packets. |
| A vulnerability has been identified in blueplanet 100 NX3 M8 (All versions), blueplanet 100 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 105 TL3 (All versions), blueplanet 105 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 110 TL3 (All versions), blueplanet 125 NX3 M10 (All versions), blueplanet 125 TL3 (All versions), blueplanet 125 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 137 TL3 (All versions), blueplanet 150 TL3 (All versions), blueplanet 150 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 155 TL3 (All versions), blueplanet 155 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 165 TL3 (All versions), blueplanet 165 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 25.0 NX3-33.0 NX3 (All versions), blueplanet 3.0 NX3-20.0 NX3 (All versions), blueplanet 3.0 TL3-60.0 TL3 (All versions), blueplanet 3.0-5.0 NX1 (All versions), blueplanet 360 NX3 M6 (All versions), blueplanet 50.0 NX3-60.0 NX3 (All versions), blueplanet 87.0 TL3 (All versions), blueplanet 87.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet 92.0 TL3 (All versions), blueplanet 92.0 TL3 GEN2 (All versions < V6.1.4.9), blueplanet gridsave 110 TL3-S (All versions < V3.91), blueplanet gridsave 137 TL3-S (All versions < V3.91), blueplanet gridsave 92.0 TL3-S (All versions < V3.91), blueplanet hybrid 10.0 TL3 (All versions), blueplanet hybrid 6.0 NH3-12.0 NH3 (All versions). A CRC16-based algorithm for generating Technical Service credentials could allow an attacker to derive the credentials from the devices serial number and misuse them to gain unauthorized access. |
| libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the `CURLOPT_SSLCERT` option (`--cert` with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like `/tmp`), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake. |
| curl 7.61.0 through 7.76.1 suffers from exposure of data element to wrong session due to a mistake in the code for CURLOPT_SSL_CIPHER_LIST when libcurl is built to use the Schannel TLS library. The selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly. |
| An issue was discovered in OpenSSH 7.9. Due to missing character encoding in the progress display, a malicious server (or Man-in-The-Middle attacker) can employ crafted object names to manipulate the client output, e.g., by using ANSI control codes to hide additional files being transferred. This affects refresh_progress_meter() in progressmeter.c. |
| Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in degamma hardware format translation
Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - Revert to operating out-of-place
This mostly reverts commit 72548b093ee3 except for the copying of
the associated data.
There is no benefit in operating in-place in algif_aead since the
source and destination come from different mappings. Get rid of
all the complexity added for in-place operation and just copy the
AD directly. |
| A vulnerability has been identified in Teamcenter V2312 (All versions < V2312.0014), Teamcenter V2406 (All versions < V2406.0012), Teamcenter V2412 (All versions < V2412.0009), Teamcenter V2506 (All versions < V2506.0005), Teamcenter V2512 (All versions). The affected application contains hardcoded key which is used for obfuscation stored directly into the application.
This could allow an attacker to obtain these keys and misuse them to gain unauthorized access. |
