linux-kernel - Using memcpy instead of copy_to

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: <CAM=k+5qEfxHOFkiXfobJERr=gMQ9jgcxgpydnkJx3ed3uPPsQg@mail.gmail.com>
Date:   Tue, 25 Jan 2022 12:03:51 -0600
From:   Aleksey Senin <aleksey-linux-kernel@...in.name>
To:     linux-kernel@...r.kernel.org
Subject: Using memcpy instead of copy_to_user. xprtrdma code.

This specific patch -  - implements using memcpy instead of
copy_to_user. Why is it considered to be safe in this specific case?
All readings about how to copy data are mentioning to use
copy_to_user/copy_from_user. Why use direct copy here? What prevents
the kernel from failure if the page is not present or doesn't have
required access rights?

@@ -103,8 +102,8 @@ static int read_reset_stat(struct ctl_table
*table, int write,
                len -= *ppos;
                if (len > *lenp)
                        len = *lenp;
-               if (len && copy_to_user(buffer, str_buf, len))
-                       return -EFAULT;
+               if (len)
+                       memcpy(buffer, str_buf, len);

Reference to the specific patch in the services of commits:
https://lkml.org/lkml/2020/4/17/60

Commit itself:
32927393dc1ccd60fb2bdc05b9e8e88753761469