0.0
NA
CVE-2023-53431
scsi: ses: Handle enclosure with just a primary component gracefully
Description

In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Handle enclosure with just a primary component gracefully This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <[email protected]>. Completely ignoring devices that have one primary enclosure and no secondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such even on valid configurations with 1 primary and 0 secondary enclosures as below: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1 The changelog for the original fix follows ===== We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process =====

INFO

Published Date :

Sept. 18, 2025, 4:15 p.m.

Last Modified :

Oct. 1, 2025, 8:15 a.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2023-53431 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Update the Linux kernel to the latest version to fix attachment issues.
  • Update the Linux kernel to the latest version.
  • Apply the patch for the scsi: ses driver.
  • Ensure enclosures have components before attaching.
  • Test the driver after applying updates.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2023-53431 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2023-53431 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2023-53431 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2023-53431 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Oct. 01, 2025

    Action Type Old Value New Value
    Changed Description In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Don't attach if enclosure has no components An enclosure with no components can't usefully be operated by the driver (since effectively it has nothing to manage), so report the problem and don't attach. Not attaching also fixes an oops which could occur if the driver tries to manage a zero component enclosure. [mkp: Switched to KERN_WARNING since this scenario is common] In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Handle enclosure with just a primary component gracefully This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <[email protected]>. Completely ignoring devices that have one primary enclosure and no secondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such even on valid configurations with 1 primary and 0 secondary enclosures as below: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1 The changelog for the original fix follows ===== We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process =====
    Added Reference https://git.kernel.org/stable/c/05143d90ac90b7abc6692285895a1ef460e008ee
    Added Reference https://git.kernel.org/stable/c/110d425cdfb15006f3c4fde5264e786a247b6b36
    Added Reference https://git.kernel.org/stable/c/176d7345b89ced72020a313bfa4e7f345d1c3aed
    Added Reference https://git.kernel.org/stable/c/4e7c498c3713b09bef20c76c7319555637e8bbd5
    Added Reference https://git.kernel.org/stable/c/c8e22b7a1694bb8d025ea636816472739d859145
    Added Reference https://git.kernel.org/stable/c/eabc4872f172ecb8dd8536bc366a51868154a450
    Added Reference https://git.kernel.org/stable/c/f8e702c54413eee2d8f94f61d18adadac7c87e87
    Removed Reference https://git.kernel.org/stable/c/3fe97ff3d94934649abb0652028dd7296170c8d0
    Removed Reference https://git.kernel.org/stable/c/4863fefc8a8cc8e8f6c7635b12d9dffaa0a12d86
    Removed Reference https://git.kernel.org/stable/c/5ca5470b33e5221dd3e5be81108697c22dd38b56
    Removed Reference https://git.kernel.org/stable/c/6069e04a922a0488bcf4f1017d38d18afda8194c
    Removed Reference https://git.kernel.org/stable/c/6fce2307650a190e343a84537c278d499fa37c26
    Removed Reference https://git.kernel.org/stable/c/d68937dfc73ee7f61cf3424fa3225be93cacaa00
    Removed Reference https://git.kernel.org/stable/c/f182ad02024d3f45374a9e0c9d76f28b776d762d
    Removed Reference https://git.kernel.org/stable/c/feefd5232ecb788f0666f75893a7a86faec8bbcc
  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 18, 2025

    Action Type Old Value New Value
    Added Description In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Don't attach if enclosure has no components An enclosure with no components can't usefully be operated by the driver (since effectively it has nothing to manage), so report the problem and don't attach. Not attaching also fixes an oops which could occur if the driver tries to manage a zero component enclosure. [mkp: Switched to KERN_WARNING since this scenario is common]
    Added Reference https://git.kernel.org/stable/c/3fe97ff3d94934649abb0652028dd7296170c8d0
    Added Reference https://git.kernel.org/stable/c/4863fefc8a8cc8e8f6c7635b12d9dffaa0a12d86
    Added Reference https://git.kernel.org/stable/c/5ca5470b33e5221dd3e5be81108697c22dd38b56
    Added Reference https://git.kernel.org/stable/c/6069e04a922a0488bcf4f1017d38d18afda8194c
    Added Reference https://git.kernel.org/stable/c/6fce2307650a190e343a84537c278d499fa37c26
    Added Reference https://git.kernel.org/stable/c/d68937dfc73ee7f61cf3424fa3225be93cacaa00
    Added Reference https://git.kernel.org/stable/c/f182ad02024d3f45374a9e0c9d76f28b776d762d
    Added Reference https://git.kernel.org/stable/c/feefd5232ecb788f0666f75893a7a86faec8bbcc
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.
Vulnerability Scoring Details
No CVSS metrics available for this vulnerability.