CVE-2023-53523 Vulnerability Analysis & Exploit Details

CVE-2023-53523
Vulnerability Scoring

Analysis In Progress

Attack Complexity Details

Attack Complexity:
Attack Complexity Analysis In Progress
Attack Vector:
Attack Vector Under Analysis
Privileges Required: None
No authentication is required for exploitation.
Scope:
Impact is confined to the initially vulnerable component.
User Interaction: None
No user interaction is necessary for exploitation.

CVE-2023-53523 Details

Status: Received on 01 Oct 2025, 12:15 UTC

Published on: 01 Oct 2025, 12:15 UTC

CVSS Release:

CVE-2023-53523 Vulnerability Summary

CVE-2023-53523: In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: fix time stamp counter initialization If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback. In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host. At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early. Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem. For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference. Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB.

Assessing the Risk of CVE-2023-53523

Access Complexity Graph

The exploitability of CVE-2023-53523 depends on two key factors: attack complexity (the level of effort required to execute an exploit) and privileges required (the access level an attacker needs).

Exploitability Analysis for CVE-2023-53523

No exploitability data is available for CVE-2023-53523.

Understanding AC and PR

A lower complexity and fewer privilege requirements make exploitation easier. Security teams should evaluate these aspects to determine the urgency of mitigation strategies, such as patch management and access control policies.

Attack Complexity (AC) measures the difficulty in executing an exploit. A high AC means that specific conditions must be met, making an attack more challenging, while a low AC means the vulnerability can be exploited with minimal effort.

Privileges Required (PR) determine the level of system access necessary for an attack. Vulnerabilities requiring no privileges are more accessible to attackers, whereas high privilege requirements limit exploitation to authorized users with elevated access.

CVSS Score Breakdown Chart

Above is the CVSS Sub-score Breakdown for CVE-2023-53523, illustrating how Base, Impact, and Exploitability factors combine to form the overall severity rating. A higher sub-score typically indicates a more severe or easier-to-exploit vulnerability.

CIA Impact Analysis

Below is the Impact Analysis for CVE-2023-53523, showing how Confidentiality, Integrity, and Availability might be affected if the vulnerability is exploited. Higher values usually signal greater potential damage.

Confidentiality: None
CVE-2023-53523 does not compromise confidentiality.
Integrity: None
CVE-2023-53523 does not impact data integrity.
Availability: None
CVE-2023-53523 does not affect system availability.

CVE-2023-53523 References

External References

CWE Common Weakness Enumeration

Unknown

Protect Your Infrastructure against CVE-2023-53523: Combat Critical CVE Threats

Stay updated with real-time CVE vulnerabilities and take action to secure your systems. Enhance your cybersecurity posture with the latest threat intelligence and mitigation techniques. Develop the skills necessary to defend against CVEs and secure critical infrastructures. Join the top cybersecurity professionals safeguarding today's infrastructures.

Other 5 Recently Published CVEs Vulnerabilities

CVE-2025-56515 – File upload vulnerability in Fiora chat application 1.0.0 through user avatar upload functionality. The application fails to validate SVG file cont...
CVE-2025-56514 – Cross Site Scripting (XSS) vulnerability in Fiora chat application 1.0.0 allows executes arbitrary JavaScript when malicious SVG files are rendered...
CVE-2023-50301 – IBM Transformation Extender Advanced 10.0.1 stores potentially sensitive information in log files that could be read by a local user.
CVE-2025-61045 – TOTOLINK X18 V9.1.0cu.2053_B20230309 was discovered to contain a command injection vulnerability via the mac parameter in the setEasyMeshAgentCfg function.
CVE-2025-61044 – TOTOLINK X18 V9.1.0cu.2053_B20230309 was discovered to contain a command injection vulnerability via the agentName parameter in the setEasyMeshAgen...