Cloudanix VulnDB

CVE-2023-53523

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Oct 1, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel when handling certain USB devices for vehicle networks could make the computer crash if the software is started or stopped at the wrong moment.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in gs_usb CAN USB driver allows NULL pointer dereference in timestamp handling when URBs are submitted before per-device cycle/time counter initialization completes during disconnect/close/open sequences.

Why it matters to the business

Systems using affected Linux kernel versions with gs_usb hardware may experience unexpected crashes, leading to loss of availability for CAN bus operations and requiring reboots or driver reloads.

How an attack unfolds

An attacker with local access unloads or unbinds the gs_usb driver, triggers CAN frame queuing in firmware during the reset window, then reloads the driver so that receive callbacks invoke timestamp conversion before initialization, causing the dereference.

How to fix it

Upgrade to fixed kernel versions: Debian 11/12/13/14 packages 5.10.46-1 or later; mainline commit 210a8cffc9c1b044281c0a868485c870c9c11374 or equivalent stable backports. Ensure driver initializes timestamp counters per device before any URB submission.

How to confirm the fix worked

Verify kernel version includes the timestamp init move and per-device conversion; test module unload/reload cycles with active CAN traffic and confirm no NULL dereference in gs_usb_receive_bulk_callback paths.

Typical attack path

  1. Obtain local access to target system with gs_usb device present
  2. Unload or unbind gs_usb driver module
  3. Allow firmware to queue CAN frames without emptying on reset
  4. Reload or bind driver to submit URBs before timestamp setup
  5. Trigger receive path on uninitialized channel to dereference NULL

How to detect it

Review kernel logs for oops or NULL pointer dereference traces involving gs_usb_timestamp_init, gs_usb_set_timestamp, or gs_usb_receive_bulk_callback during driver load/unload; correlate with USB disconnect events on CAN interfaces.

What your security team should do

  • Prioritize kernel updates on all systems exposing gs_usb CAN interfaces
  • Audit for gs_usb usage in embedded or automotive deployments
  • Monitor for driver reload events in high-availability CAN environments

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.1.0 6.4.7
SUSE:Linux Enterprise High Availability Extension 15 SP6 kernel-default 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise High Availability Extension 15 SP7 kernel-default 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-default 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-livepatch-SLE15-SP6-RT_Update_16 0 1-150600.1.3.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-livepatch-SLE15-SP6_Update_16 0 1-150600.13.3.1
SUSE:Linux Enterprise Live Patching 15 SP7 kernel-default 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Live Patching 15 SP7 kernel-livepatch-SLE15-SP7_Update_6 0 1-150700.15.3.1
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-64kb 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-default 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-default-base 0 6.4.0-150600.23.73.1.150600.12.32.1
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-source 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-zfcpdump 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Basesystem 15 SP7 kernel-64kb 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Basesystem 15 SP7 kernel-default 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Basesystem 15 SP7 kernel-default-base 0 6.4.0-150700.53.22.1.150700.17.15.1
SUSE:Linux Enterprise Module for Basesystem 15 SP7 kernel-source 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Basesystem 15 SP7 kernel-zfcpdump 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-docs 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-obs-build 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-source 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-syms 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Development Tools 15 SP7 kernel-docs 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Development Tools 15 SP7 kernel-obs-build 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Development Tools 15 SP7 kernel-source 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Development Tools 15 SP7 kernel-syms 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Legacy 15 SP6 kernel-default 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Module for Legacy 15 SP7 kernel-default 0 6.4.0-150700.53.22.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-azure 0 6.4.0-150600.8.52.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-source-azure 0 6.4.0-150600.8.52.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-syms-azure 0 6.4.0-150600.8.52.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP7 kernel-azure 0 6.4.0-150700.20.18.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP7 kernel-source-azure 0 6.4.0-150700.20.18.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP7 kernel-syms-azure 0 6.4.0-150700.20.18.1
SUSE:Linux Enterprise Workstation Extension 15 SP6 kernel-default 0 6.4.0-150600.23.73.1
SUSE:Linux Enterprise Workstation Extension 15 SP7 kernel-default 0 6.4.0-150700.53.22.1
SUSE:Real Time Module 15 SP6 kernel-rt 0 6.4.0-150600.10.55.1
SUSE:Real Time Module 15 SP6 kernel-rt_debug 0 6.4.0-150600.10.55.1
SUSE:Real Time Module 15 SP6 kernel-source-rt 0 6.4.0-150600.10.55.1
SUSE:Real Time Module 15 SP6 kernel-syms-rt 0 6.4.0-150600.10.55.1
openSUSE:Leap 15.6 dtb-aarch64 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-64kb 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-azure 0 6.4.0-150600.8.52.1
openSUSE:Leap 15.6 kernel-debug 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-default 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-default-base 0 6.4.0-150600.23.73.1.150600.12.32.1
openSUSE:Leap 15.6 kernel-docs 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-kvmsmall 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-obs-build 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-obs-qa 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-rt 0 6.4.0-150600.10.55.1
openSUSE:Leap 15.6 kernel-rt_debug 0 6.4.0-150600.10.55.1
openSUSE:Leap 15.6 kernel-source 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-source-azure 0 6.4.0-150600.8.52.1
openSUSE:Leap 15.6 kernel-source-rt 0 6.4.0-150600.10.55.1
openSUSE:Leap 15.6 kernel-syms 0 6.4.0-150600.23.73.1
openSUSE:Leap 15.6 kernel-syms-azure 0 6.4.0-150600.8.52.1
openSUSE:Leap 15.6 kernel-syms-rt 0 6.4.0-150600.10.55.1
openSUSE:Leap 15.6 kernel-zfcpdump 0 6.4.0-150600.23.73.1

Related vulnerabilities