linux-kernel - [BUG] copy_file_range with sysfs file as input

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com>
Date:   Mon, 25 Jan 2021 15:54:31 +0800
From:   Nicolas Boichat <drinkcat@...omium.org>
To:     "Darrick J. Wong" <djwong@...nel.org>,
        linux-fsdevel@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
        Amir Goldstein <amir73il@...il.com>,
        Dave Chinner <dchinner@...hat.com>
Cc:     Luis Lozano <llozano@...omium.org>, iant@...gle.com
Subject: [BUG] copy_file_range with sysfs file as input

Hi copy_file_range experts,

We hit this interesting issue when upgrading Go compiler from 1.13 to
1.15 [1]. Basically we use Go's `io.Copy` to copy the content of
`/sys/kernel/debug/tracing/trace` to a temporary file.

Under the hood, Go now uses `copy_file_range` syscall to optimize the
copy operation. However, that fails to copy any content when the input
file is from sysfs/tracefs, with an apparent size of 0 (but there is
still content when you `cat` it, of course).

A repro case is available in comment7 (adapted from the man page),
also copied below [2].

Output looks like this (on kernels 5.4.89 (chromeos), 5.7.17 and
5.10.3 (chromeos))
$ ./copyfrom /sys/kernel/debug/tracing/trace x
0 bytes copied
$ cat x
$ cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0   #P:8
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |

I can try to dig further, but thought you'd like to get a bug report
as soon as possible.

Thanks,

Nicolas

[1] http://issuetracker.google.com/issues/178332739
[2]
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>

int
main(int argc, char **argv)
{
        int fd_in, fd_out;
        loff_t ret;

        if (argc != 3) {
                fprintf(stderr, "Usage: %s <source> <destination>\n", argv[0]);
                exit(EXIT_FAILURE);
        }

        fd_in = open(argv[1], O_RDONLY);
        if (fd_in == -1) {
                perror("open (argv[1])");
                exit(EXIT_FAILURE);
        }

        fd_out = open(argv[2], O_CREAT | O_WRONLY | O_TRUNC, 0644);
        if (fd_out == -1) {
                perror("open (argv[2])");
                exit(EXIT_FAILURE);
        }

        ret = copy_file_range(fd_in, NULL, fd_out, NULL, 1024, 0);
        if (ret == -1) {
                perror("copy_file_range");
                exit(EXIT_FAILURE);
        }
        printf("%d bytes copied\n", (int)ret);

        close(fd_in);
        close(fd_out);
        exit(EXIT_SUCCESS);
}