FTBFS: arm64, riscv64: ‘read’ writing 1 byte into a region of size 0 overflows the destination

This is happening on arm64 because __NR_signalfd is not defined there. arm64 only has __NR_signalfd4[1]

The following #ifdef[2] in usr/util.h then fails:

#if defined(__NR_signalfd) && defined(USE_SIGNALFD)
...

And we end up in the #else clause, which:
#else
#define __signalfd(fd, mask, flags) (-1)
struct signalfd_siginfo {
};
#endif

This essentially makes this struct zero, and gcc/glibc is now catching that in usr/bs.c[3]:

 struct signalfd_siginfo siginfo[16];
...
 ret = read(fd, (char *)siginfo, sizeof(siginfo));

sizeof(siginfo) is zero, so nothing should be written, but this is tripping the -Wstringop-overflow check.

I also wonder if we are incorrectly building tgt without signalfd support for all this time, unknowingly, because of this...

1. https://github.com/bminor/glibc/blob/f9ac84f92f151e07586c55e14ed628d493a5929d/sysdeps/unix/sysv/linux/aarch64/arch-syscall.h#L255

2. https://github.com/fujita/tgt/blob/master/usr/util.h#L106

3. https://github.com/fujita/tgt/blob/master/usr/bs.c#L196

I think this is a false positive. Here is a quick reproducer on amd64:
#include <stdio.h>
#include <unistd.h>

int main(void) {
    struct test_st {};
    int fd = 0;
    int count = 0;

    struct test_st test_info[16];

    printf("Hello world\n");
    printf("sizeof struct test_st: %ld\n", sizeof(struct test_st));
    printf("sizeof test_info[16]: %ld\n", sizeof(test_info));
    count = read(fd, test_info, sizeof(test_info)); /* invalid fd, don't care */
    printf("count is %d\n", count);
    return(0);
}

When this is built with -D_FORTIFY_SOURCE=3 *and* -O2 (or -O1 even), it issues the same warning:
$ gcc foo.c -o foo -D_FORTIFY_SOURCE=3 -O2
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<built-in>: note: this is the location of the previous definition
foo.c: In function ‘main’:
foo.c:14:13: warning: ‘read’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
   14 | count = read(fd, test_info, sizeof(test_info));
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
foo.c:9:20: note: destination object ‘test_info’ of size 0
    9 | struct test_st test_info[16];
      | ^~~~~~~~~
In file included from /usr/include/unistd.h:1214,
                 from foo.c:2:
/usr/include/x86_64-linux-gnu/bits/unistd.h:26:1: note: in a call to function ‘read’ declared with attribute ‘access (write_only, 2)’
   26 | read (int __fd, void *__buf, size_t __nbytes)
      | ^~~~

But note that read(2) with a count of zero will not overflow the target, as nothing will be read, so this seems like a bug in gcc. And indeed, there are several[1] such bug reports in gcc's bugzilla. Where it got the "1 byte" I don't know.

1. https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=writing%201%20byte%20into%20a%20region%20of%20size%200

Some discussion happening on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922

It turns out that this is probably a glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=31383

Just to be clear, which version of glibc are we talking about here, the one in noble-proposed or the one in the release pocket?

I confirmed the ftbfs with noble-release as well.

The reproducer from comment #2 happens also in my mantic machine.

tgt upstream replied[1] with a patch dropping the workaround which triggered this glibc/gcc bug.

1. https://www.spinics.net/lists/linux-stgt/msg04784.html

without patch: (noble-release)
root@Unimatrix08-Jammy:/# tgtd -f
tgtd: iser_ib_init(3431) Failed to initialize RDMA; load kernel modules?
tgtd: work_timer_start(146) use timer_fd based scheduler
tgtd: bs_init(393) use pthread notification

with upstream patch:
root@Unimatrix08-Jammy:/# tgtd -f
tgtd: iser_ib_init(3431) Failed to initialize RDMA; load kernel modules?
tgtd: work_timer_start(146) use timer_fd based scheduler
tgtd: bs_init(387) use signalfd notification

Description:
bs.c: In function ‘bs_sig_request_done’:
bs.c:196:15: error: ‘read’ writing 1 byte into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  196 | ret = read(fd, (char *)siginfo, sizeof(siginfo));
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bs.c:193:33: note: destination object ‘siginfo’ of size 0
  193 | struct signalfd_siginfo siginfo[16];
      | ^~~~~~~
In file included from /usr/include/unistd.h:1217,
                 from bs.c:33:
/usr/include/aarch64-linux-gnu/bits/unistd.h:26:1: note: in a call to function ‘read’ declared with attribute ‘access (write_only, 2)’
   26 | read (int __fd, void *__buf, size_t __nbytes)
      | ^~~~
Origin: Upstream https://www.spinics.net/lists/linux-stgt/msg04784.html
Last-Update: 2024-02-15

diff --git a/usr/bs.c b/usr/bs.c
index 8171a32..8da5a9b 100644
--- a/usr/bs.c
+++ b/usr/bs.c
@@ -311,7 +311,7 @@ static int bs_init_signalfd(void)
  sigaddset(&mask, SIGUSR2);
  sigprocmask(SIG_BLOCK, &mask, NULL);

- sig_fd = __signalfd(-1, &mask, 0);
+ sig_fd = signalfd(-1, &mask, 0);
  if (sig_fd < 0)
   return 1;

diff --git a/usr/util.h b/usr/util.h
index c709f9b..8aef6ab 100644
--- a/usr/util.h
+++ b/usr/util.h
@@ -14,6 +14,7 @@
 #include <string.h>
 #include <limits.h>
 #include <linux/types.h>
+#include <sys/signalfd.h>

 #include "be_byteshift.h"

@@ -99,44 +101,6 @@ static inline int between(uint32_t seq1, uint32_t seq2, uint32_t seq3)

 extern unsigned long pagesize, pageshift;

-#if defined(__NR_signalfd) && defined(USE_SIGNALFD)
-
-/*
- * workaround for broken linux/signalfd.h including
- * usr/include/linux/fcntl.h
- */
-#define _LINUX_FCNTL_H
-
-#include <linux/signalfd.h>
-
-static inline int __signalfd(int fd, const sigset_t *mask, int flags)
-{
- int fd2, ret;
-
- fd2 = syscall(__NR_signalfd, fd, mask, _NSIG / 8);
- if (fd2 < 0)
- return fd2;
-
- ret = fcntl(fd2, F_GETFL);
- if (ret < 0) {
- close(fd2);
- return -1;
- }
-
- ret = fcntl(fd2, F_SETFL, ret | O_NONBLOCK);
- if (ret < 0) {
- close(fd2);
- return -1;
- }
-
- return fd2;
-}
-#else
-#define __signalfd(fd, mask, flags) (-1)
-struct signalfd_siginfo {
-};
-#endif
-
 /* convert string to integer, check for validity of the string numeric format
  * and the natural boundaries of the integer value type (first get a 64-bit
  * value and check that it fits the range of the destination integer).

(due to an error in the closing bug syntax, this bug has been manually closed!)