104 matches found
CVE-2024-8361
In SiWx91x devices, the SHA2/224 algorithm returns a hash of 256 bits instead of 224 bits. This incorrect hash length triggers a software assertion, which subsequently causes a Denial of Service DoS. If a watchdog is implemented, device will restart after watch dog expires. If watchdog is not...
CVE-2024-8361 DoS caused due to wrong hash length returned for SHA2/224 algorithm
In SiWx91x devices, the SHA2/224 algorithm returns a hash of 256 bits instead of 224 bits. This incorrect hash length triggers a software assertion, which subsequently causes a Denial of Service DoS. If a watchdog is implemented, device will restart after watch dog expires. If watchdog is not...
CVE-2024-7138
An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7139 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7139 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7139 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7139
The CVE-2024-7139 entry concerns Silicon Labs RS9116 Bluetooth SDK. The issue is caused by an unchecked buffer length in L2CAP processing, allowing a buffer overflow that triggers an assertion and leads to a temporary denial of service. The impact is a DoS, with a potential required hard reset to...
CVE-2024-7138 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7138 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog timer is not enabled, a hard reset is required to recover the device...
CVE-2024-7137 Denial of Service in Silicon Labs RS9116 Bluetooth SDK
The L2CAP receive data buffer for L2CAP packets is restricted to packet sizes smaller than the maximum supported packet size. Receiving a packet that exceeds the restricted buffer length may cause a crash. A hard reset is required to recover the crashed device...
PT-2024-38103 · Bluetooth · Bluetooth
Name of the Vulnerable Software and Affected Versions: Bluetooth affected versions not specified Description: The issue is related to the L2CAP receive data buffer for L2CAP packets, which is restricted to packet sizes smaller than the maximum supported packet size. Receiving a packet that exceed...
PT-2024-38104 · Silabs.Com · Rs9116 Bluetooth Sdk
Name of the Vulnerable Software and Affected Versions: No specific software or versions are mentioned in the provided descriptions. Description: An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog tim...
CVE-2024-6657
A denial of service may be caused to a single peripheral device in a BLE network when multiple central devices continuously connect and disconnect to the peripheral. A hard reset is required to recover the peripheral device...
CVE-2024-6657 BLE peripheral DoS after few cycles of connect/disconnects
A denial of service may be caused to a single peripheral device in a BLE network when multiple central devices continuously connect and disconnect to the peripheral. A hard reset is required to recover the peripheral device...
CVE-2024-6657 BLE peripheral DoS after few cycles of connect/disconnects
A denial of service may be caused to a single peripheral device in a BLE network when multiple central devices continuously connect and disconnect to the peripheral. A hard reset is required to recover the peripheral device...
CVE-2024-6657
CVE-2024-6657 affects Siemens Sentron Powercenter 1000/1100 BLE subsystem. A denial-of-service can occur in a BLE network when multiple central devices repeatedly connect/disconnect to a peripheral, with recovery requiring a hard reset. The DoS is linked to synchronization errors in the BLE compo...
PT-2024-9466 · Siemens · Sentron Powercenter 1000/1100
Name of the Vulnerable Software and Affected Versions: Sentron Powercenter 1000/1100 affected versions not specified Description: A denial of service issue may occur in a BLE network when multiple central devices continuously connect and disconnect to a peripheral device, requiring a hard reset t...
CVE-2024-44961
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before1, soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascadin...
CVE-2024-44961 drm/amdgpu: Forward soft recovery errors to userspace
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before1, soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascadin...
SUSE CVE-2024-40976
In the Linux kernel, the following vulnerability has been resolved: drm/lima: mask irqs in timeout path before hard reset There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is do...