带有 MSG_TRUNC 的 Linux TCP recv() - 写入缓冲区？

Question

我刚刚遇到了令人惊讶的缓冲区溢出，同时尝试在 TCP 套接字上的 recv 中使用标志 MSG_TRUNC。

而且它似乎只发生在 gcc （而不是 clang）上，并且只有在使用优化编译时才会发生。

根据这个链接：http: //man7.org/linux/man-pages/man7/tcp.7.html

从 2.4 版开始，Linux 支持在 recv(2)（和 recvmsg(2)）的 flags 参数中使用 MSG_TRUNC。 此标志导致接收到的数据字节被丢弃，而不是在调用者提供的缓冲区中传回。 从 Linux 2.4.4 开始，MSG_PEEK 在与 MSG_OOB 结合使用以接收带外数据时也具有此效果。

这是否意味着不会写入提供的缓冲区？ 我是这么想的，但很惊讶。 如果您传递一个缓冲区（非零指针）并且大小大于缓冲区大小，则当客户端发送大于缓冲区的内容时会导致缓冲区溢出。 如果消息很小并且适合缓冲区（没有溢出），它实际上似乎不会将消息写入缓冲区。 显然，如果您传递一个空指针，问题就会消失。

客户端是一个简单的 netcat，发送大于 4 个字符的消息。

服务器代码基于： http ://www.linuxhowtos.org/data/6/server.c

使用 MSG_TRUNC 将读取更改为 recv，并将缓冲区大小更改为 4（bzero 也更改为 4）。

在 Ubuntu 14.04 上编译。 这些编译工作正常（没有警告）：

gcc -o server.x server.c

clang -o server.x server.c

clang -O2 server.x server.c

这是错误（？）编译，它还给出了有关问题的警告提示：

gcc -O2 -o server.x server.c

无论如何，就像我提到的将指针更改为 null 可以解决问题，但这是一个已知问题吗？ 还是我错过了手册页中的某些内容？

更新：

gcc -O1 也会发生缓冲区溢出。 这是编译警告：

在函数“recv”中，从 server.c:47:14 的“main”内联：/usr/include/x86_64-linux-gnu/bits/socket2.h:42:2：警告：调用声明为“__recv_chk_warn”属性警告：recv 调用的长度大于目标缓冲区的大小 [默认启用] return __recv_chk_warn (__fd, __buf, __n, __bos0 (__buf), __flags);

这是缓冲区溢出：

./server.x 10003 * 检测到缓冲区溢出 * : ./server.x 终止 ======= 回溯：========= /lib/x86_64-linux-gnu/libc.so.6 (+0x7338f)[0x7fcbdc44b38f] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fcbdc4e2c9c] /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fcbdc4e1b60] /lib/x86_64-linux-gnu/libc.so.6(+0x10a023)[0x7fcbdc4e2023] ./server.x[0x400a6c] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fcbdc3f9ec5 ] ./server.x[0x400879] ======= 内存映射：======== 00400000-00401000 r-xp 00000000 08:01 17732 > /tmp/server.x ... 更多消息这里中止（核心转储）

和 gcc 版本：

gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

缓冲区和 recv 调用：

字符缓冲区[4]；

n = recv(newsockfd,buffer,255,MSG_TRUNC);

这似乎解决了它：

n = recv(newsockfd,NULL,255,MSG_TRUNC);

这不会产生任何警告或错误：

gcc -Wall -Wextra -pedantic -o server.x server.c

这是完整的代码：

/* A simple server in the internet domain using TCP
   The port number is passed as an argument */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h> 
#include <sys/socket.h>
#include <netinet/in.h>

void error(const char *msg)
{
    perror(msg);
    exit(1);
}

int main(int argc, char *argv[])
{
     int sockfd, newsockfd, portno;
     socklen_t clilen;
     char buffer[4];
     struct sockaddr_in serv_addr, cli_addr;
     int n;
     if (argc < 2) {
         fprintf(stderr,"ERROR, no port provided\n");
         exit(1);
     }
     sockfd = socket(AF_INET, SOCK_STREAM, 0);
     if (sockfd < 0) 
        error("ERROR opening socket");
     bzero((char *) &serv_addr, sizeof(serv_addr));
     portno = atoi(argv[1]);
     serv_addr.sin_family = AF_INET;
     serv_addr.sin_addr.s_addr = INADDR_ANY;
     serv_addr.sin_port = htons(portno);
     if (bind(sockfd, (struct sockaddr *) &serv_addr,
              sizeof(serv_addr)) < 0) 
              error("ERROR on binding");
     listen(sockfd,5);
     clilen = sizeof(cli_addr);
     newsockfd = accept(sockfd, 
                 (struct sockaddr *) &cli_addr, 
                 &clilen);
     if (newsockfd < 0) 
          error("ERROR on accept");
     bzero(buffer,4);
     n = recv(newsockfd,buffer,255,MSG_TRUNC);
     if (n < 0) error("ERROR reading from socket");
     printf("Here is the message: %s\n",buffer);
     n = write(newsockfd,"I got your message",18);
     if (n < 0) error("ERROR writing to socket");
     close(newsockfd);
     close(sockfd);
     return 0; 
}

更新：也发生在 Ubuntu 16.04 上，带有 gcc 版本：

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

Answer 1

我想你误会了。

对于数据报套接字， MSG_TRUNC选项的行为如man 2 recv手册页中所述（在Linux 联机手册页中可以获得最准确和最新的信息）。

对于 TCP 套接字， man 7 tcp手册页中的解释措辞有些拙劣。 我相信这不是丢弃标志，而是截断（或“丢弃其余部分” ）操作。 但是，实现（特别是 Linux 内核中的net/ipv4/tcp.c:tcp_recvmsg()函数处理 TCP/IPv4 和 TCP/IPv6 套接字的详细信息）表明并非如此。

还有一个单独的MSG_TRUNC套接字标志。 这些存储在与套接字关联的错误队列中，可以使用recvmsg(socketfd, &msg, MSG_ERRQUEUE)读取。 它表示读取的数据报比缓冲区长，因此其中一些数据报丢失（截断）。 这很少使用，因为它实际上只与数据报套接字相关，并且有更简单的方法来确定超长数据报。

---

数据报套接字：

使用数据报套接字，消息是分开的，而不是合并的。 读取时，每个接收到的数据报的未读部分被丢弃。

如果你使用

    nbytes = recv(socketfd, buffer, buffersize, MSG_TRUNC);

这意味着内核将复制下一个数据报的第一个buffersize字节，如果数据报更长（像往常一样），则丢弃其余的数据报，但nbytes将反映数据报的真实长度。

换句话说，使用MSG_TRUNC ， nbytes可能会超过buffersize ，即使只有最多buffersize个字节被复制到buffer 。

---

Linux，内核 2.4 及更高版本中的 TCP 套接字，已编辑：

TCP 连接是流式的； 没有“消息”或“消息边界”，只有一个字节序列流动。 （虽然可以有带外数据，但这在这里不相关）。

如果你使用

    nbytes = recv(socketfd, buffer, buffersize, MSG_TRUNC);

内核将丢弃多达下一个buffersize字节，无论已经缓冲了什么（但将阻塞直到至少一个字节被缓冲，除非套接字处于非阻塞模式或使用MSG_TRUNC | MSG_DONTWAIT代替）。 丢弃的字节数以nbytes形式返回。

但是， buffer和buffersize都应该是有效的，因为recv()或recvfrom()调用通过内核net/socket.c:sys_recvfrom()函数，该函数验证buffer和buffersize是否有效，如果是，则填充内部在调用上述net/ipv4/tcp.c:tcp_recvmsg()之前要匹配的迭代器结构。

换句话说，带有MSG_TRUNC标志的recv()实际上并没有尝试修改buffer 。 但是，内核确实会检查buffer和buffersize大小是否有效，如果不是，将导致recv()系统调用失败并显示-EFAULT 。

当启用缓冲区溢出检查时，GCC 和 glibc recv()不只是返回-1和errno==EFAULT ； 相反，它会停止程序，产生所示的回溯。 其中一些检查包括映射零页面（ NULL指针的目标驻留在 x86 和 x86-64 上的 Linux 中），在这种情况下，内核完成的访问检查（在实际尝试读取或写入之前）成功.

为了避免 GCC/glibc 包装器（以便使用例如 gcc 和 clang 编译的代码应该表现相同），可以使用real_recv()代替，

#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <errno.h>

ssize_t real_recv(int fd, void *buf, size_t n, int flags)
{
    long retval = syscall(SYS_recvfrom, fd, buf, n, flags, NULL, NULL);
    if (retval < 0) {
        errno = -retval;
        return -1;
    } else
        return (ssize_t)retval;
}

它直接调用系统调用。 请注意，这不包括 pthreads 取消逻辑； 仅在单线程测试程序中使用它。

---

总之，在使用 TCP 套接字时，关于recv()的MSG_TRUNC标志的所述问题，有几个因素使整个情况复杂化：

• recv(sockfd, data, size, flags)实际上调用了recvfrom(sockfd, data, size, flags, NULL, NULL)系统调用（Linux 中没有recv系统调用）

• 使用 TCP 套接字时，如果(char *)data+0到(char *)data+size-1有效，则recv(sockfd, data, size, MSG_TRUNC)的行为就像将最多size个字节读入data ； 它只是不将它们复制到data中。 返回这样跳过的字节数。

• 内核首先验证data （从(char *)data+0到(char *)data+size-1 ，包括）是否可读。 （我怀疑这个检查是错误的，将来可能会变成一个可写性检查，所以不要依赖这是一个可读性测试。）

• 缓冲区溢出检查可以检测来自内核的-EFAULT结果，而是使用某种“越界”错误消息（带有堆栈跟踪）暂停程序

• 从内核的角度来看，缓冲区溢出检查可能会使NULL指针看起来有效（因为当前内核测试是用于读取），在这种情况下，内核验证接受NULL指针为有效。 （可以通过在没有缓冲区溢出检查的情况下重新编译来验证是否是这种情况，例如使用上面的real_recv() ，然后查看NULL指针是否导致-EFAULT结果。）

  这种映射的原因（如果硬件和内核结构允许，则仅存在，并且不可读取或不可写入）是通过这样的映射，任何访问都会生成一个SIGBUS信号，该信号（库或编译器提供）信号处理程序）不仅可以捕获和转储堆栈跟踪，还可以捕获有关确切访问的更多详细信息（地址、尝试访问的代码等）。

  我确实相信内核访问检查将此类映射视为可读和可写的，因为需要进行读取或写入尝试才能生成信号。

• 缓冲区溢出检查由编译器和 C 库完成，因此不同的编译器可能会以不同的方式实现检查和NULL指针的情况。

Answer 2

注意：经过这么长时间，我在这里添加了这个答案，因为这仍然是谷歌上关于recv buffer overflow MSG_TRUNC的第一个结果之一，如果其他人最终来到这里，他们会为自己省去很多悲伤，搜索和试错。

最初的问题已经得到了很好的回答，但我想强调的微妙之处在于流和数据报套接字之间的区别。

一个常见的代码模式是使用recv( socket_, NULL, 0, MSG_DONTWAIT | MSG_PEEK | MSG_TRUNC )来查找在读取之前排队的数据量。 这对于流套接字（TCP 和 SCTP）非常有效，但对于数据报套接字（UDP、UDPL 和 DCCP），它会间歇性地缓冲溢出，但前提是使用gcp编译可执行文件并启用优化。 如果没有优化，它似乎可以完美运行，这意味着它将通过开发 QA，只是在 staging/live 中失败。

发现这是一个完整的 PITA。 别客气。 ;)