All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eshaan Deshmukh" <eshaan2031@icloud.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v4 3/3] scsi: libsas: Handle errors in sas_ex_discover_expander()
Date: Wed, 19 Aug 2026 03:38:50 +0000	[thread overview]
Message-ID: <20260819033851.4746A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819032321.493746-4-eshaan2031@icloud.com>

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 <eshaan2031@icloud.com>

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/20260819032321.493746-1-eshaan2031@icloud.com?part=3

      reply	other threads:[~2026-08-19  3:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19  3:23 [PATCH v4 0/3] Fix control flow in sas_ex_add_parent_port() Eshaan Deshmukh
2026-08-19  3:23 ` [PATCH v4 1/3] scsi: libsas: Handle errors " Eshaan Deshmukh
2026-08-19  3:33   ` sashiko-bot
2026-08-19  3:23 ` [PATCH v4 2/3] scsi: libsas: Handle errors in sas_set_ex_phy() Eshaan Deshmukh
2026-08-19  3:37   ` sashiko-bot
2026-08-19  3:23 ` [PATCH v4 3/3] scsi: libsas: Handle errors in sas_ex_discover_expander() Eshaan Deshmukh
2026-08-19  3:38   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260819033851.4746A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eshaan2031@icloud.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.