similar to: [PATCH libnbd] configure: Ban use of Variable Length Arrays (VLAs).

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also in highly multithreaded code with limited stack sizes (as nbdkit

On 9/5/19 6:28 AM, Richard W.M. Jones wrote: > I'm not someone who thinks VLAs are automatically bad and unlike Linux > kernel code they can sometimes be used safely in userspace. However > for an internet exposed server there is an argument that they might > cause some kind of exploitable situation especially if the code is > compiled without other stack hardening features.

Now that previous patches have cleaned up shadowing warnings, it's worth preventing any further relapses. Signed-off-by: Eric Blake <eblake at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4c92e2b1..5842c6f9 100644 --- a/configure.ac +++ b/configure.ac @@ -90,7 +90,7 @@ AC_ARG_ENABLE([gcc-warnings],

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable cmdline_size. Also, remove cmdline_size as it is not >> actually

While working on can_FOO caching, at one point I got confused by whether 'readonly' meant the global set by -r or a local passed to .open(). A quick attempt to compile with -Wshadow found several other confusing points; this series gets us to the point that we can add -Wshadow to builds with --enable-gcc-warnings. Eric Blake (10): server: Avoid -Wshadow warnings guestfs: Avoid

On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keescook at chromium.org> wrote: > On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: >>> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >>>> In preparation to enabling -Wvla,

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

Older GCC versions (e.g. < 4.9) may complain about inline functions that cannot be inlined (growing the generated code). It is not really a problem for us, so just suppress again the warning. Followup of commit c37c554fc56151b709882b382bb5fa26d9083449. --- m4/guestfs_c.m4 | 1 + 1 file changed, 1 insertion(+) diff --git a/m4/guestfs_c.m4 b/m4/guestfs_c.m4 index 7250294..ea26202 100644 ---

When valgrinding plugins, the following sequence can happen: plugin_free -> dlclose -> unloads the plugin and symbol table exit -> valgrind prints failures (the same applies to filters). When valgrind is printing the failures, it looks up the addresses in the symbol table, but that has been unloaded already so all you see are "???", resulting in useless

The previous commit broke the build during 'make check'; we want to test the in-tree header, not some (potentially stale or missing) installed header. Signed-off-by: Eric Blake <eblake at redhat.com> --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index c2d473a..9076d6b 100644 --- a/tests/Makefile.am

On Sun, Mar 3, 2024 at 4:46?AM Duoming Zhou <duoming at zju.edu.cn> wrote: > > The kcalloc() in nouveau_dmem_evict_chunk() will return null if > the physical memory has run out. As a result, if we dereference > src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs > will happen. > > This patch uses stack variables to replace the kcalloc(). Won't this

On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA. In this particular > case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local > variable cmdline_size. Also, remove cmdline_size as it is not > actually useful anymore. > > The use of stack Variable Length Arrays needs to be avoided, as they > can be

On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: >> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >>> In preparation to enabling -Wvla, remove VLA. In this particular >>> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of

On Thu, May 24, 2018 at 8:48 AM, Kees Cook <keescook at chromium.org> wrote: > On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keescook at chromium.org> wrote: >> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: >>>> On Tue, Mar 13, 2018 at

--- configure.ac | 2 ++ filters/blocksize/Makefile.am | 1 + filters/cache/Makefile.am | 1 + filters/cacheextents/Makefile.am | 1 + filters/cow/Makefile.am | 1 + filters/ddrescue/Makefile.am | 1 + filters/delay/Makefile.am | 3 +++ filters/error/Makefile.am | 1 + filters/exitlast/Makefile.am | 3 +++

Two simple patches which make libnbd compile on FreeBSD. Are we OK to copy common/include/byte-swapping.h from nbdkit? There is no license issue that I know of. Should we put it in lib/ or create a common/ directory? The header file is actually also needed by the tests (follow up patch for that) so putting it in common/ might make more sense. Some notes if you want to compile on FreeBSD: -

After fixing some warnings (see prior commits), we can now enable them in configure.ac. --- m4/guestfs_c.m4 | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/m4/guestfs_c.m4 b/m4/guestfs_c.m4 index e91446f..7250294 100644 --- a/m4/guestfs_c.m4 +++ b/m4/guestfs_c.m4 @@ -43,22 +43,15 @@ fi dnl This, $nw, is the list of warnings we disable. nw= nw="$nw

This borrows from a trick in libvirt - by defining $(NULL) to expand to an empty string, we can more consistently write multi-line macros where all useful lines terminate with \, making it easier to add/remove lines without worrying about whether \ needs to be touched up on neighboring lines. --- Looks big, but is fairly mechanical. I'm also doing a similar patch for nbdkit, where it would

CentOS 6 has libguestfs-devel 1.20.11, which predates the support in guestfs_add_drive_opts() for requesting an nbd drive instead of a local file (annoyingly, guestfs documentation merely states the function was available since 0.3, without saying which later releases added new options); causing a compilation failure during 'make check'. Maybe the guestfs plugin should still be built,