CVE-2023-53431

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