search for: fortify_sourc

...t; >> /usr/include/bits/stdlib.h:37:8: note: previous definition is here > >> __NTH (realpath (const char *__restrict __name, char *__restrict > __resolved)) > > > > > > I've never seen this before. Looks like bits/stdlib.h gets pulled in only > > when _FORTIFY_SOURCE is enabled (which causes > > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE > > set somewhere? > > I do, it's by default a part of hardening flags on most Linux distros, > and I'm just following what the distro packages are built with. > > > Can you...

...in llvm that would be fixed if only we were calling "secure" functions? What's the impact of calling the secure function? On Release builds and on Debug builds? On size and performance? Why not rely on platforms to secure these functions? For instance, Linux and Darwin both have FORTIFY_SOURCE, and I'm too ignorant of Windows to know what the equivalent is there. What about existing tools like valgrind or ASAN? What happens if memcpy_secure does detect an insecure memcpy? It's considered very rude for LLVM to terminate on the spot since it's often used as a library, so...

...lib.h:37:8: note: previous definition is here >> >> __NTH (realpath (const char *__restrict __name, char *__restrict >> __resolved)) >> > >> > >> > I've never seen this before. Looks like bits/stdlib.h gets pulled in >> only >> > when _FORTIFY_SOURCE is enabled (which causes >> > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE >> > set somewhere? >> >> I do, it's by default a part of hardening flags on most Linux distros, >> and I'm just following what the distro packages are built with. &gt...

...s utility sends me a mail whenever there is a change regarding the vulnerabilities' status on my system. It lists new ones, resolved ones and current ones. Is there anything similar for CentOS? 2) I read that RHEL packages are compiled with various security technologies including Exec Shield, FORTIFY_SOURCE and fstack-protector. Does this apply to CentOS too? Thanks! Regards, Luigi

..._OPTION_IF([-Wno-shift-negative-value],[ + NO_SNV_CFLAGS="-Wno-shift-negative-value" +]) +AC_SUBST([NO_SNV_CFLAGS]) + AC_DEFINE([lint], [1], [Define to 1 if the compiler is checking for lint.]) AC_DEFINE([GNULIB_PORTCHECK], [1], [Enable some gnulib portability checks.]) AH_VERBATIM([FORTIFY_SOURCE],[ -- 2.13.6

...{ >> ^ >> /usr/include/bits/stdlib.h:37:8: note: previous definition is here >> __NTH (realpath (const char *__restrict __name, char *__restrict __resolved)) > > > I've never seen this before. Looks like bits/stdlib.h gets pulled in only > when _FORTIFY_SOURCE is enabled (which causes > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE > set somewhere? I do, it's by default a part of hardening flags on most Linux distros, and I'm just following what the distro packages are built with. > Can you try with that not set? I can try...

Hello, We have identified functions in LLVM sources using a static code analyzer which are marked as a "security vulnerability"[1][2]. There has been work already done to address some of them for Linux (e.g. snprintf). We are attempting to solve this issue in a comprehensive fashion across all platforms. Most of the functions identified are for manipulating strings. Memcpy is the most

> On Dec 20, 2016, at 5:49 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ​Hi again, Teresa. > > Looks like I had forgotten to report back with success > when finally building 3.9.0 in ThinLTO linker mode > back in October. Sorry about that and thanks for > helping me out. I know how important it is to get > success reports as well, as a

We routinely test the upstream code by running everything under valgrind, and in any case _FORTIFY_SOURCE is usually defined by downstream Linux distros and we can leave the optimization vs safety decision to them. See this bug: https://bugs.gentoo.org/640494 --- m4/guestfs-c.m4 | 6 ------ 1 file changed, 6 deletions(-) diff --git a/m4/guestfs-c.m4 b/m4/guestfs-c.m4 index 932b6de73..3e8642675 1006...

Martijn van Beurden wrote: > > 'chown', declared with attribute warn_unused_result [-Wunused-result] > > metadata_iterators.c:3299:2: warning: ignoring return value of > > 'chown', declared with attribute warn_unused_result [-Wunused-result] > > In file included from /usr/include/stdio.h:934:0, Thats an Ubuntu special. They have patched their libc headers

Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length array declaration in struct nvfw_hs_load_header_v2 with flex-array member. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Link: https...

SSIA Martin Kletzander (2): Don't redefine _FORTIFY_SOURCE Get rid of gnulib error bootstrap | 2 +- configure.ac | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 1.8.3.2

...2, qla2xxx, qla6312, sata_nv, > sata_promise, sata_svw, sata_sx4, sata_vsc, cifs > * Driver additions including > bnx2, dell_rbu, ib_mthca, megaraid_sas, qla2400, typhoon > > - Security enhancements: > * Execshield updates > * Begin use of gcc FORTIFY_SOURCE build option in some > package updates > * SELinux policy updates > * Updated kernel key management support > > - System tools enhancements: > * SystemTap dynamic system instrumentation tool enhancements > including technology preview for bro...

Dear R-devel, I have encountered a crash-inducing scenario and would like to enquire as to whether this would be considered a bug. To reproduce the crash: X <- sample(letters, 3000, TRUE) D <- data.frame(X, 1:3000, X, X, X, X, X) D$X1.3000 <- paste0("GSM", D) The reason why I'm not sure if this would be considered a bug is because I typed this by accident, when what I

Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic), As a follow-up to that old thread about -D_FORTIFY_SOURCE=n http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE support is claimed to be only partial: https://pagure.io/fesco/issue/2020 I dig into the glibc headers in order to have a better understandin...

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a