linux.git/drivers/scsi/libfc, branch v6.6.131

scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill()

2025-11-24T09:29:43+00:00

[ Upstream commit 072fdd4b0be9b9051bdf75f36d0227aa705074ba ]

The fc_ct_ms_fill() helper currently formats the OS name and version
into entry->value using "%s v%s". Since init_utsname()->sysname and
->release are unbounded strings, snprintf() may attempt to write more
than FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN bytes, triggering a
-Wformat-truncation warning with W=1.

In file included from drivers/scsi/libfc/fc_elsct.c:18:
drivers/scsi/libfc/fc_encode.h: In function ‘fc_ct_ms_fill.constprop’:
drivers/scsi/libfc/fc_encode.h:359:30: error: ‘%s’ directive output may
be truncated writing up to 64 bytes into a region of size between 62
and 126 [-Werror=format-truncation=]
  359 |                         "%s v%s",
      |                              ^~
  360 |                         init_utsname()->sysname,
  361 |                         init_utsname()->release);
      |                         ~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/libfc/fc_encode.h:357:17: note: ‘snprintf’ output between
3 and 131 bytes into a destination of size 128
  357 |                 snprintf((char *)&entry->value,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  358 |                         FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN,
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  359 |                         "%s v%s",
      |                         ~~~~~~~~~
  360 |                         init_utsname()->sysname,
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~
  361 |                         init_utsname()->release);
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~

Fix this by using "%.62s v%.62s", which ensures sysname and release are
truncated to fit within the 128-byte field defined by
FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN.

[mkp: clarified commit description]

Signed-off-by: Alok Tiwari 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: libfc: Fix up timeout error in fc_fcp_rec_error()

2024-02-05T20:14:20+00:00

[ Upstream commit 53122a49f49796beb2c4a1bb702303b66347e29f ]

We should set the status to FC_TIMED_OUT when a timeout error is passed to
fc_fcp_rec_error().

Signed-off-by: Hannes Reinecke 
Link: https://lore.kernel.org/r/20231129165832.224100-3-hare@kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: libfc: Don't schedule abort twice

2024-02-05T20:14:20+00:00

[ Upstream commit b57c4db5d23b9df0118a25e2441c9288edd73710 ]

The current FC error recovery is sending up to three REC (recovery) frames
in 10 second intervals, and as a final step sending an ABTS after 30
seconds for the command itself.  Unfortunately sending an ABTS is also the
action for the SCSI abort handler, and the default timeout for SCSI
commands is also 30 seconds. This causes two ABTS to be scheduled, with the
libfc one slightly earlier. The ABTS scheduled by SCSI EH then sees the
command to be already aborted, and will always return with a 'GOOD' status
irrespective on the actual result from the first ABTS.  This causes the
SCSI EH abort handler to always succeed, and SCSI EH never to be engaged.
Fix this by not issuing an ABTS when a SCSI command is present for the
exchange, but rather wait for the abort scheduled from SCSI EH.  And warn
if an abort is already scheduled to avoid similar errors in the future.

Signed-off-by: Hannes Reinecke 
Link: https://lore.kernel.org/r/20231129165832.224100-2-hare@kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()

2023-11-28T17:19:43+00:00

[ Upstream commit 4df105f0ce9f6f30cda4e99f577150d23f0c9c5f ]

fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed.

Signed-off-by: Wenchao Hao 
Link: https://lore.kernel.org/r/20231011130350.819571-1-haowenchao2@huawei.com
Reviewed-by: Simon Horman 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: libfc: Include the correct header

2022-12-01T03:03:36+00:00

This file does not use rcu, so there is no point in including
.

The dependency has been removed in commit fa519f701d27 ("scsi: libfc: fixup
'sleeping function called from invalid context'") It turned a
list_for_each_entry_rcu() into a list_for_each_entry().

So just #include  now.

Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/960f34418358f0c35e645aa2cf7e0ec7fe6b60b9.1669461197.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Martin K. Petersen

scsi: libfc: Remove redundant variable ev_qual

2022-11-17T18:14:14+00:00

Variable ev_qual is being assigned and modified but the end result is never
used. The variable is redundant and can be removed.

Signed-off-by: Colin Ian King 
Link: https://lore.kernel.org/r/20221111170824.558250-1-colin.i.king@gmail.com
Signed-off-by: Martin K. Petersen

scsi: libfc: Remove get_cpu() semantics in fc_exch_em_alloc()

2022-05-17T01:26:50+00:00

The get_cpu() in fc_exch_em_alloc() was introduced in commit f018b73af6db
("[SCSI] libfc, libfcoe, fcoe: use smp_processor_id() only when preempt
disabled") for no other reason than to simply use smp_processor_id()
without getting a warning, because everything is done with the pool->lock
held anyway.  However, get_cpu(), by disabling preemption, does not play
well with PREEMPT_RT, particularly when acquiring a regular (and thus
sleepable) spinlock.

Therefore remove the get_cpu() and just use the unstable value as we will
have CPU locality guarantees next by taking the lock.  The window of
migration, as noted by Sebastian, is small and even if it happens the
result is correct.

Link: https://lore.kernel.org/r/20211117025956.79616-2-dave@stgolabs.net
Link: https://lore.kernel.org/r/20220506105758.283887-4-bigeasy@linutronix.de
Acked-by: Sebastian Andrzej Siewior 
Signed-off-by: Davidlohr Bueso 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Martin K. Petersen

scsi: fcoe: Use per-CPU API to update per-CPU statistics

2022-05-17T01:26:50+00:00

The per-CPU statistics (struct fc_stats) is updated by getting a stable
per-CPU pointer via get_cpu() + per_cpu_ptr() and then performing the
increment. This can be optimized by using this_cpu_*() which will do
whatever is needed on the architecture to perform the update safe and
efficient.  The read out of the individual value (fc_get_host_stats())
should be done by using READ_ONCE() instead of a plain-C access. The
difference is that READ_ONCE() will always perform a single access while
the plain-C access can be split by the compiler into two loads if it
appears beneficial.  The usage of u64 has the side-effect that it is also
64bit wide on 32bit architectures and the read is always split into two
loads. The can lead to strange values if the read happens during an update
which alters both 32bit parts of the 64bit value. This can be circumvented
by either using a 32bit variables on 32bit architecures or extending the
statistics with a sequence counter.

Use this_cpu_*() API to update the statistics and READ_ONCE() to read it.

Link: https://lore.kernel.org/r/20220506105758.283887-3-bigeasy@linutronix.de
Reviewed-by: Davidlohr Bueso 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Martin K. Petersen

scsi: libfc: Fix use after free in fc_exch_abts_resp()

2022-03-09T03:32:31+00:00

fc_exch_release(ep) will decrease the ep's reference count. When the
reference count reaches zero, it is freed. But ep is still used in the
following code, which will lead to a use after free.

Return after the fc_exch_release() call to avoid use after free.

Link: https://lore.kernel.org/r/20220303015115.459778-1-niejianglei2021@163.com
Reviewed-by: Hannes Reinecke 
Signed-off-by: Jianglei Nie 
Signed-off-by: Martin K. Petersen

scsi: libfc: Replace one-element arrays with flexible-array members

2022-02-28T02:17:37+00:00

Use flexible-array members in struct fc_fdmi_attr_entry and fs_fdmi_attrs
instead of one-element arrays, and refactor the code accordingly.

Also, this helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines on
memcpy().

https://github.com/KSPP/linux/issues/79
https://github.com/ClangBuiltLinux/linux/issues/1590

Link: https://lore.kernel.org/r/20220214223903.GA859464@embeddedor
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Martin K. Petersen