| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
strncpy() is deprecated [1] and as such we should use different apis to
copy string data.
We can see that ct is NUL-initialized with fc_ct_hdr_fill:
| ct = fc_ct_hdr_fill(fp, op, sizeof(struct fc_ns_rspn) + len,
...
In fc_ct_hdr_fill():
| memset(ct, 0, ct_plen);
We also calculate the length of the source string:
| len = strnlen(fc_host_symbolic_name(lport->host), 255);
...then this argument is used in strncpy(), which is bad because the
pattern of (dest, src, strlen(src)) usually leaves the destination
buffer without NUL-termination. However, it looks as though we do not
require NUL-termination since fr_name is part of a seq_buf-like
structure wherein its length is monitored:
| struct fc_ns_rspn {
| struct fc_ns_fid fr_fid; /* port ID object */
| __u8 fr_name_len;
| char fr_name[];
| } __attribute__((__packed__));
So, this is really just a byte copy into a length-bounded buffer. Let's use
memcpy().
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240221-strncpy-drivers-scsi-libfc-fc_encode-h-v2-1-019a0889c5ca@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
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 <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add all attributes for RHBA and RPA registration.
Fallback mechanism is added between RBHA V2 and RHBA V1 attributes. In case
RHBA get fails for V2 attributes we fall back to V1 attribute registration.
Link: https://lore.kernel.org/r/20210603121623.10084-4-jhasan@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Javed Hasan <jhasan@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Incorrect condition check was leading to data corruption.
Link: https://lore.kernel.org/r/20210603101404.7841-3-jhasan@marvell.com
Fixes: 8fd9efca86d0 ("scsi: libfc: Work around -Warray-bounds warning")
CC: stable@vger.kernel.org
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Javed Hasan <jhasan@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Building libfc with gcc -Warray-bounds identifies a number of cases in one
file where a strncpy() is performed into a single-byte character array:
In file included from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from include/linux/smp.h:13,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:59,
from include/linux/debugobjects.h:6,
from include/linux/timer.h:8,
from include/scsi/libfc.h:11,
from drivers/scsi/libfc/fc_elsct.c:17:
In function 'strncpy',
inlined from 'fc_ct_ms_fill.constprop' at drivers/scsi/libfc/fc_encode.h:235:3:
include/linux/string.h:290:30: warning: '__builtin_strncpy' offset [56, 135] from the object at 'pp' is out of the bounds of referenced subobject 'value' with type '__u8[1]' {aka 'unsigned char[1]'} at offset 56 [-Warray-bounds]
290 | #define __underlying_strncpy __builtin_strncpy
| ^
include/linux/string.h:300:9: note: in expansion of macro '__underlying_strncpy'
300 | return __underlying_strncpy(p, q, size);
| ^~~~~~~~~~~~~~~~~~~~
This is not a bug because the 1-byte array is used as an odd way to express
a variable-length data field here. I tried to convert it to a
flexible-array member, but in the end could not figure out why the
sizeof(struct fc_fdmi_???) are used the way they are, and how to properly
convert those.
Work around this instead by abstracting the string copy in a slightly
higher-level function fc_ct_hdr_fill() helper that strscpy() and memset()
to achieve the same result as strncpy() but does not require a
zero-terminated input and does not get checked for the array overflow
because gcc (so far) does not understand the behavior of strscpy().
Link: https://lore.kernel.org/r/20201026160705.3706396-2-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Most of this file is only used inside of libfc, so move it to where it is
actually used, with only fc_fill_fc_hdr() left inside of the header.
Link: https://lore.kernel.org/r/20201026160705.3706396-1-arnd@kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
