- 20 Jun, 2023 2 commits
-
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). Direct replacement is safe here since return value from all callers of STRLCPY macro were ignored. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
Azeem Shaikh <azeemshaikh38@gmail.com> Acked-by:
Jozsef Kadlecsik <kadlec@netfilter.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
- 14 Jun, 2023 6 commits
-
-
Kees Cook authored
When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrproper" target not cleaning up arch/x86/... when SUBARCH was specified. Since HOST_DIR is arch/$(HEADER_ARCH), use it instead to get the correct path. Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Azeem Shaikh <azeemshaikh38@gmail.com> Cc: linux-um@lists.infradead.org Fixes: 7bbe7204 ("um: merge Makefile-{i386,x86_64}") Cc: stable@vger.kernel.org Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
- 05 Jun, 2023 5 commits
-
-
Andy Shevchenko authored
Since strreplace() returns the pointer to the string itself, we may use it directly in the code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
It's more useful to return the pointer to the string itself with strreplace(), so it may be used like attr->name = strreplace(name, '/', '_'); While at it, amend the kernel documentation. Signed-off-by:
-
Andy Shevchenko authored
Theoretically possible that "%pg" will take all room for the j_devname and hence the "-%lu" will go outside the boundary due to unconditional sprintf() in use. To make this code more robust, replace two sequential s*printf():s by a single call and then replace forbidden character. It's possible to do this way, because '/' won't ever be in the result of "-%lu". Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Kees Cook authored
Fake flexible arrays have been deprecated since last millennium. Proper C99 flexible arrays must be used throughout the kernel so CONFIG_FORTIFY_SOURCE and CONFIG_UBSAN_BOUNDS can provide proper array bounds checking. Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Fixed-by:
Joe Perches <joe@perches.com> Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
-
Kees Cook authored
With the addition of -fstrict-flex-arrays=3, struct sha256_state's trailing array is no longer ignored by CONFIG_FORTIFY_SOURCE: struct sha256_state { u32 state[SHA256_DIGEST_SIZE / 4]; u64 count; u8 buf[SHA256_BLOCK_SIZE]; }; This means that the memcpy() calls with "buf" as a destination in sha256.c's code will attempt to perform run-time bounds checking, which could lead to calling missing functions, specifically a potential WARN_ONCE, which isn't callable from purgatory. Reported-by:Thorsten Leemhuis <linux@leemhuis.info> Closes: https://lore.kernel.org/lkml/175578ec-9dec-7a9c-8d3a-43f24ff86b92@leemhuis.info/Bisected-by:
"Joan Bruguera Micó" <joanbrugueram@gmail.com> Fixes: df8fc4e9 ("kbuild: Enable -fstrict-flex-arrays=3") Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Conor Dooley <conor.dooley@microchip.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Alyssa Ross <hi@alyssa.is> Cc: Heiko Stuebner <heiko.stuebner@vrull.eu> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-riscv@lists.infradead.org Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Palmer Dabbelt <palmer@rivosinc.com> Acked-by:
-
- 01 Jun, 2023 11 commits
-
-
Kees Cook authored
With the addition of -fstrict-flex-arrays=3, struct sha256_state's trailing array is no longer ignored by CONFIG_FORTIFY_SOURCE: struct sha256_state { u32 state[SHA256_DIGEST_SIZE / 4]; u64 count; u8 buf[SHA256_BLOCK_SIZE]; }; This means that the memcpy() calls with "buf" as a destination in sha256.c's code will attempt to perform run-time bounds checking, which could lead to calling missing functions, specifically a potential WARN_ONCE, which isn't callable from purgatory. Reported-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230531003414.never.050-kees@kernel.org
-
Kees Cook authored
With the addition of -fstrict-flex-arrays=3, struct sha256_state's trailing array is no longer ignored by CONFIG_FORTIFY_SOURCE: struct sha256_state { u32 state[SHA256_DIGEST_SIZE / 4]; u64 count; u8 buf[SHA256_BLOCK_SIZE]; }; This means that the memcpy() calls with "buf" as a destination in sha256.c's code will attempt to perform run-time bounds checking, which could lead to calling missing functions, specifically a potential WARN_ONCE, which isn't callable from purgatory. Reported-by:Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/20230531003345.never.325-kees@kernel.org
-
Wyes Karny authored
struct acpi_table_slit is used for copying System Locality Information Table data from ACPI tables. Here `entry` is a flex array but it was using ancient 1-element fake flexible array, which has been deprecated. Replace it with a C99 flexible array. Signed-off-by:
Wyes Karny <wyes.karny@amd.com> Reviewed-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
John Stultz <jstultz@google.com> Signed-off-by:
-
Alexander Potapenko authored
lib/string.c is built with -ffreestanding, which prevents the compiler from replacing certain functions with calls to their library versions. On the other hand, this also prevents Clang and GCC from instrumenting calls to memcpy() when building with KASAN, KCSAN or KMSAN: - KASAN normally replaces memcpy() with __asan_memcpy() with the additional cc-param,asan-kernel-mem-intrinsic-prefix=1; - KCSAN and KMSAN replace memcpy() with __tsan_memcpy() and __msan_memcpy() by default. To let the tools catch memory accesses from strlcpy/strlcat, replace the calls to memcpy() with __builtin_memcpy(), which KASAN, KCSAN and KMSAN are able to replace even in -ffreestanding mode. This preserves the behavior in normal builds (__builtin_memcpy() ends up being replaced with memcpy()), and does not introduce new instrumentation in unwanted places, as strlcpy/strlcat are already instrumented. Suggested-by:
Marco Elver <elver@google.com> Signed-off-by:
Alexander Potapenko <glider@google.com> Reviewed-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
- 30 May, 2023 8 commits
-
-
Arnd Bergmann authored
Most of the functions in ubsan that are only called from generated code don't have a prototype, which W=1 builds warn about: lib/ubsan.c:226:6: error: no previous prototype for '__ubsan_handle_divrem_overflow' [-Werror=missing-prototypes] lib/ubsan.c:307:6: error: no previous prototype for '__ubsan_handle_type_mismatch' [-Werror=missing-prototypes] lib/ubsan.c:321:6: error: no previous prototype for '__ubsan_handle_type_mismatch_v1' [-Werror=missing-prototypes] lib/ubsan.c:335:6: error: no previous prototype for '__ubsan_handle_out_of_bounds' [-Werror=missing-prototypes] lib/ubsan.c:352:6: error: no previous prototype for '__ubsan_handle_shift_out_of_bounds' [-Werror=missing-prototypes] lib/ubsan.c:394:6: error: no previous prototype for '__ubsan_handle_builtin_unreachable' [-Werror=missing-prototypes] lib/ubsan.c:404:6: error: no previous prototype for '__ubsan_handle_load_invalid_value' [-Werror=missing-prototypes] Add prototypes for all of these to lib/ubsan.h, and remove the one that was already present in ubsan.c. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Fangrui Song <maskray@google.com> Signed-off-by:
-
Kees Cook authored
Warn about strcpy(), strncpy(), and strlcpy(). Suggest strscpy() and include pointers to the open KSPP issues for each, which has further details and replacement procedures. Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
-
Kees Cook authored
In an effort to annotate all flexible array members with their run-time size information, the "element_count" attribute is being introduced by Clang[1] and GCC[2] in future releases. This annotation will provide the CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE features the ability to perform run-time bounds checking on otherwise unknown-size flexible arrays. Even though the attribute is under development, we can start the annotation process in the kernel. This requires defining a macro for it, even if we have to change the name of the actual attribute later. Since it is likely that this attribute may change its name to "counted_by" in the future (to better align with a future total bytes "sized_by" attribute), name the wrapper macro "__counted_by", which also reads more clearly (and concisely) in structure definitions. [1] https://reviews.llvm.org/D148381 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 Cc: Bill Wendling <morbo@google.com> Cc: Qing Zhao <qing.zhao@oracle.com> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Tom Rix <trix@redhat.com> Cc: llvm@lists.linux.dev Signed-off-by:
Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20230517190841.gonna.796-kees@kernel.org
-
Arnd Bergmann authored
Commit df8fc4e9 ("kbuild: Enable -fstrict-flex-arrays=3") introduced a warning for the autofs_dev_ioctl structure: In function 'check_name', inlined from 'validate_dev_ioctl' at fs/autofs/dev-ioctl.c:131:9, inlined from '_autofs_dev_ioctl' at fs/autofs/dev-ioctl.c:624:8: fs/autofs/dev-ioctl.c:33:14: error: 'strchr' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] 33 | if (!strchr(name, '/')) | ^~~~~~~~~~~~~~~~~ In file included from include/linux/auto_dev-ioctl.h:10, from fs/autofs/autofs_i.h:10, from fs/autofs/dev-ioctl.c:14: include/uapi/linux/auto_dev-ioctl.h: In function '_autofs_dev_ioctl': include/uapi/linux/auto_dev-ioctl.h:112:14: note: source object 'path' of size 0 112 | char path[0]; | ^~~~ This is easily fixed by changing the gnu 0-length array into a c99 flexible array. Since this is a uapi structure, we have to be careful about possible regressions but this one should be fine as they are equivalent here. While it would break building with ancient gcc versions that predate c99, it helps building with --std=c99 and -Wpedantic builds in user space, as well as non-gnu compilers. This means we probably also want it fixed in stable kernels. Cc: stable@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Cc: Gustavo A. R. Silva" <gustavoars@kernel.org> Signed-off-by:
-
Kees Cook authored
The testing for ARRAY_BOUNDS just wants an uninstrumented array, and the proper flexible array definition is fine for that. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Bill Wendling <morbo@google.com> Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated. In an effort to remove strlcpy() completely, replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Kees Cook authored
Replace old-style 1-element array of "dev" in struct stripe_head with modern C99 flexible array. In the future, we can additionally annotate it with the run-time size, found in the "disks" member. Cc: Song Liu <song@kernel.org> Cc: linux-raid@vger.kernel.org Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Song Liu <song@kernel.org> Signed-off-by:
-
- 26 May, 2023 8 commits
-
-
Kees Cook authored
While struct_size() is normally used in situations where the structure type already has a pointer instance, there are places where no variable is available. In the past, this has been worked around by using a typed NULL first argument, but this is a bit ugly. Add a helper to do this, and replace the handful of instances of the code pattern with it. Instances were found with this Coccinelle script: @struct_size_t@ identifier STRUCT, MEMBER; expression COUNT; @@ - struct_size((struct STRUCT *)\(0\|NULL\), + struct_size_t(struct STRUCT, MEMBER, COUNT) Suggested-by:Christoph Hellwig <hch@infradead.org> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: James Smart <james.smart@broadcom.com> Cc: Keith Busch <kbusch@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: HighPoint Linux Team <linux@highpoint-tech.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Sumit Saxena <sumit.saxena@broadcom.com> Cc: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Cc: Don Brace <don.brace@microchip.com> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: Dave Chinner <dchinner@redhat.com> Cc: Guo Xuenan <guoxuenan@huawei.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Daniel Latypov <dlatypov@google.com> Cc: kernel test robot <lkp@intel.com> Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Cc: linux-nvme@lists.infradead.org Cc: linux-scsi@vger.kernel.org Cc: megaraidlinux.pdl@broadcom.com Cc: storagedev@microchip.com Cc: linux-xfs@vger.kernel.org Cc: linux-hardening@vger.kernel.org Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Darrick J. Wong <djwong@kernel.org> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://lore.kernel.org/r/20230522211810.never.421-kees@kernel.org
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement with strlcpy is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
-
