LiveActive security incident?Get immediate response
CVE Record

CVE-2023-54117: s390/dcssblk: fix kernel crash with list_add corruption

In the Linux kernel, the following vulnerability has been resolved: s390/dcssblk: fix kernel crash with list_add corruption Commit fb08a1908cb1 ("dax: simplify the dax_device <-> gendisk association") introduced new logic for gendisk association, requiring drivers to explicitly call dax_add_host() and dax_remove_host(). For dcssblk driver, some dax_remove_host() calls were missing, e.g. in device remove path. The commit also broke error handling for out_dax case in device add path, resulting in an extra put_device() w/o the previous get_device() in that case. This lead to stale xarray entries after device add / remove cycles. In the case when a previously used struct gendisk pointer (xarray index) would be used again, because blk_alloc_disk() happened to return such a pointer, the xa_insert() in dax_add_host() would fail and go to out_dax, doing the extra put_device() in the error path. In combination with an already flawed error handling in dcssblk (device_register() cleanup), which needs to be addressed in a separate patch, this resulted in a missing device_del() / klist_del(), and eventually in the kernel crash with list_add corruption on a subsequent device_add() / klist_add(). Fix this by adding the missing dax_remove_host() calls, and also move the put_device() in the error path to restore the previous logic.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel stability bug in the s390 dcssblk driver. Device add/remove handling can leave stale DAX host associations, later triggering list corruption and a kernel crash. The business impact is mainly availability on affected IBM s390/Linux systems using this driver.

Executive priority

Schedule remediation for affected s390 Linux systems, especially where downtime has business impact. This is not currently evidenced as internet-exploited, but kernel crashes can cause service interruption.

Technical view

The bug follows commit fb08a1908cb1, where dcssblk missed dax_remove_host() calls and had faulty out_dax error handling. Repeated device add/remove cycles can leave stale xarray entries; later dax_add_host() failure and cleanup imbalance can lead to missing device_del()/klist_del() and list_add corruption.

Likely exposure

Likely limited to Linux on s390 environments using the dcssblk driver and affected kernel builds. The source bundle does not prove exposure for general Linux servers or non-s390 systems.

Exploitation context

No KEV listing, public exploitation claim, CVSS score, or exploitability details are provided. The described failure mode is a kernel crash after device lifecycle operations, so treat it as an availability risk unless vendor evidence says otherwise.

Researcher notes

The source attributes the issue to missing dax_remove_host() calls and an erroneous put_device() path after the DAX/gendisk association change. Version evidence in the bundle is incomplete, so confirm exact affected and fixed ranges through kernel or distribution advisories.

Mitigation direction

  • Check whether s390 dcssblk is used in affected Linux kernels.
  • Apply the relevant Linux stable kernel fix from vendor guidance.
  • Prioritize systems where untrusted users can influence dcssblk device lifecycle operations.
  • If patching is delayed, reduce operational exposure to dcssblk add/remove paths.
  • Track distribution advisories for backported fixed kernel packages.

Validation and detection

  • Inventory kernel versions on s390 Linux hosts.
  • Confirm whether the dcssblk module or feature is enabled.
  • Map installed kernels to vendor advisories or listed stable commits.
  • Review kernel logs for dcssblk, DAX, xarray, or list_add corruption crashes.
  • Validate remediation by confirming the fixed kernel package or backported patch.
Prepared
Confidence
medium
Sources
6

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-54117 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
5Source 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
LinuxLinuxfb08a1908cb119a4585611d91461ab6d27756b14, fb08a1908cb119a4585611d91461ab6d27756b14, fb08a1908cb119a4585611d91461ab6d27756b14, fb08a1908cb119a4585611d91461ab6d27756b14unaffected
LinuxLinux5.17, 0, 6.1.53, 6.4.16, 6.5.3, 6.6affected
Weakness

CWE details

No CWE listed

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