From: Alok Tiwari alok.a.tiwari@oracle.com
[ 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 alok.a.tiwari@oracle.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - The updated format string in `drivers/scsi/libfc/fc_encode.h:356` caps both `init_utsname()->sysname` and `init_utsname()->release` at 62 characters, keeping the composed `"OS vversion"` entry within the 128-byte field defined for `FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN` at `include/scsi/fc/fc_ms.h:92`. This directly prevents the -Wformat- truncation build failure reported when compiling with `make W=1`, so it resolves a real build bug without changing any control flow. - Runtime impact is limited to at most two characters of each component being truncated, which is already acceptable for this management payload and smaller than the silent truncation that happened previously when both strings were long. - The patch is tiny, self-contained in libfc’s FDMI attribute formatting helper, and introduces no dependency or architectural change, so regression risk is negligible while restoring clean W=1 builds for stable users who enable those checks.
drivers/scsi/libfc/fc_encode.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/libfc/fc_encode.h b/drivers/scsi/libfc/fc_encode.h index 02e31db31d68e..e046091a549ae 100644 --- a/drivers/scsi/libfc/fc_encode.h +++ b/drivers/scsi/libfc/fc_encode.h @@ -356,7 +356,7 @@ static inline int fc_ct_ms_fill(struct fc_lport *lport, put_unaligned_be16(len, &entry->len); snprintf((char *)&entry->value, FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN, - "%s v%s", + "%.62s v%.62s", init_utsname()->sysname, init_utsname()->release);