Alexey Izbyshev: "I think that we can even drop dup-based validation from is_valid_fd() since there is a corner case for Linux too: if a descriptor opened with O_PATH inherited as a standard one, dup() will succeed but fstat() will fail in kernels before 3.6. And we do fstat() almost immediately after is_valid_fd() to get blksize, so the dup-based optimization doesn't seem worth the trouble. Victor, do you have an opinion on that?"

I don't understand this case. I don't know O_PATH nor how to inherit such special file descriptor. Would you mind to elaborate?

man open:

       O_PATH (since Linux 2.6.39)
              Obtain a file descriptor that can be used for two  purposes:  to
              indicate a location in the filesystem tree and to perform opera‐
              tions that act purely at the file descriptor  level.   The  file
              itself  is not opened, and other file operations (e.g., read(2),
              write(2), fchmod(2), fchown(2), fgetxattr(2), ioctl(2), mmap(2))
              fail with the error EBADF.

In following C program, fd 0 is a file descriptor opened by O_PATH: dup(0) and fstat(0) both succeed, which is not surprising, it's a valid file descriptor.
---
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

#define O_PATH 010000000

int main(void)
{
    int path_fd;

    path_fd = open(".", O_PATH);

    if (dup2(path_fd, 0)) {
        perror("dup2");
    }

    int fd = dup(0);
    if (fd < 0)
        perror("dup");
    else {
        fprintf(stderr, "dup ok: %d\n", fd);
        close(fd);
    }

    struct stat st;
    if (fstat(0, &st) < 0) {
        perror("fstat");
    }
    else {
        printf("fstat ok\n");
    }

    return 0;
}
---