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 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:
# 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] 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 sesintfremove_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