Re: [PATCH v4 3/3] scsi: libsas: Handle errors in sas_ex_discover_expander()

[email protected]
Newsgroups org.kernel.vger.linux-scsi
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unchecked return value from `sas_expander_alloc()` causes a fatal out-of-bounds write/kernel panic when accessing `edev->level`.
- [High] Ignoring the return value of `sas_rphy_add(rphy)` leads to driver core crashes and invalid subsystem state.
--

--- Patch [3]: [PATCH v4 3/3] scsi: libsas: Handle errors in  sas_ex_discover_expander() ---
(Note: Due to system recitation restrictions, this review uses a free-form summary format instead of inline patch quoting.)

commit 44af8b2a020232c7d2be451e3b31502443d8fc4d
Author: Eshaan Deshmukh <[email protected]>

scsi: libsas: Handle errors in sas_ex_discover_expander()

This commit improves error handling in sas_ex_discover_expander() by checking
the return values of sas_port_alloc() and sas_port_add(). If either function
fails, it performs proper cleanup and returns NULL.

In drivers/scsi/libsas/sas_expander.c:sas_ex_discover_expander()

[Severity: High]
This is a pre-existing issue, but does this code risk a panic under memory
pressure?

The function calls sas_expander_alloc() to allocate rphy, but does not
check if the return value is NULL. Later, it calls
rphy_to_expander_device(rphy) which uses container_of() and subtracts the
offset of rphy. If rphy is NULL, edev becomes a negative pointer. The
subsequent write to edev->level = parent_ex->level + 1 would then
unconditionally panic the kernel.

[Severity: High]
This isn't a bug introduced by this patch, but does ignoring the return
value of sas_rphy_add() lead to a crash during error recovery?

The code calls sas_rphy_add(rphy) without checking its return value. If
sas_rphy_add() fails, the internal device_add() fails, meaning the device
was never actually added to the system. 

If the subsequent call to sas_discover_expander(child) also fails, the
error handling path calls sas_rphy_delete(rphy). This attempts to call
device_del() on a device that was never successfully added, which will
dereference uninitialized fields and crash the driver core.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.