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.
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.
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.
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.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 1, 2025, 11:46 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.