netdev - LTP recv/recvmsg tests failing on 3.17

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]

Date:	Tue, 23 Sep 2014 09:11:08 -0500
From:	Chuck Ebbert <cebbert.lkml@...il.com>
To:	Willem de Bruijn <willemb@...gle.com>
Cc:	netdev@...r.kernel.org
Subject: LTP recv/recvmsg tests failing on 3.17

LTP tests recv01, recvfrom01 and recvmsg01 are reporting failure on
their "invalid flags" tests on 3.17. They pass a value of -1 for flags
and expect to get EINVAL back, but now they get EAGAIN. It looks like
this is due to:

commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b
Author: Willem de Bruijn <willemb@...gle.com>
Date:   Mon Aug 4 22:11:49 2014 -0400

    net-timestamp: TCP timestamping

which adds this hunk to net/ipv4/tcp.c:

@@ -1617,6 +1630,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
        struct sk_buff *skb;
        u32 urg_hole = 0;
 
+       if (unlikely(flags & MSG_ERRQUEUE))
+               return ip_recv_error(sk, msg, len, addr_len);
+
        if (sk_can_busy_loop(sk) && skb_queue_empty(&sk->sk_receive_queue) &&
            (sk->sk_state == TCP_ESTABLISHED))
                sk_busy_loop(sk, nonblock);

Before this change, the first flag tested was MSG_OOB, which eventually
causes EINVAL to be returned. Now this flag gets tested first, and
ip_recv_err() returns EAGAIN.

LTP setting every flag and expecting behavior to remain unchanged is
probably wrong, but is EAGAIN correct here? I can't find any spec for
this.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html