asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
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>
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>
