DEBIAN-CVE-2023-53431

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 numenclosures) does exist. That fix was originally proposed by Ding Hui dinghui@sangfor.com.cn. Completely ignoring devices that have one primary enclosure and no secondary one results in sesintfadd() 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: # sgses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sgses -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] sesintfremove at ffff000001f200e4 [ffff00002a00fbd0] devicedel at ffff0000086b6a98 [ffff00002a00fc50] deviceunregister at ffff0000086b6d58 [ffff00002a00fc70] _scsiremovedevice at ffff00000870608c [ffff00002a00fca0] scsiremovedevice at ffff000008706134 [ffff00002a00fcc0] _scsiremovetarget at ffff0000087062e4 [ffff00002a00fd10] scsiremovetarget at ffff0000087064c0 [ffff00002a00fd70] _iscsiunbindsession at ffff000001c872c4 [ffff00002a00fdb0] processonework at ffff00000810f35c [ffff00002a00fe00] workerthread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In sesintfadd, 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 sesintfremoveenclosure, 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 sesenclosuredata_process =====