LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53523: can: gs_usb: fix time stamp counter initialization

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

CVE-2023-53523 is a Linux kernel crash issue in the gs_usb CAN driver. Under a specific unload or unbind timing, queued CAN frames can be processed before timestamp state is initialized, causing a NULL pointer dereference. Business impact is primarily availability for systems using this driver with USB CAN interfaces.

Executive priority

Treat as a targeted availability risk, not a broad enterprise emergency. Prioritize patching for industrial, automotive, lab, or embedded Linux systems that rely on USB CAN connectivity and gs_usb stability.

Technical view

The bug affects gs_usb timestamp initialization around RX URB submission. Queued frames from a device, including candlelight firmware behavior noted in the source, can reach gs_usb_receive_bulk_callback() before timecounter state exists. The fix initializes timestamping before URBs and converts timestamp state from per-channel to per-device.

Likely exposure

Exposure appears limited to Linux systems using the gs_usb CAN driver with affected kernel versions or downstream builds lacking the referenced stable fixes. Systems not using gs_usb USB CAN devices are unlikely to be exposed based on the provided sources.

Exploitation context

The sources do not state active exploitation, and the CVE is not marked KEV. The described trigger requires a driver unload or unbind before interface shutdown, with queued CAN frames later processed after rebind or reload.

Researcher notes

Evidence supports a kernel NULL pointer dereference in gs_usb receive handling after specific driver lifecycle ordering. No CVSS, CWE, exploit code, or confirmed exploitation is provided. Affected-version details in the bundle are sparse, so downstream vendor kernel mapping is required.

Mitigation direction

  • Update to a kernel containing the referenced stable gs_usb fixes.
  • Check Linux distribution advisories for patched kernel package versions.
  • Prioritize systems that use gs_usb USB CAN interfaces.
  • Avoid operational workflows that unload or unbind gs_usb before interface shutdown until patched.

Validation and detection

  • Inventory Linux hosts using gs_usb USB CAN interfaces.
  • Confirm kernel builds include commits 210a8cffc9c1 or 5886e4d5ecec.
  • Review kernel logs for gs_usb NULL pointer dereference crashes.
  • Check whether affected systems use multi-channel gs_usb devices.
Prepared
Confidence
medium
Sources
4

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-53523 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux45dfa45f52e66f8eee30a64b16550a9c47915044, 45dfa45f52e66f8eee30a64b16550a9c47915044unaffected
LinuxLinux6.1, 0, 6.4.7, 6.5affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.