netdev - Re: 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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 23 Sep 2014 10:57:41 -0400
From:	Willem de Bruijn <willemb@...gle.com>
To:	Chuck Ebbert <cebbert.lkml@...il.com>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: Re: LTP recv/recvmsg tests failing on 3.17

On Tue, Sep 23, 2014 at 10:11 AM, Chuck Ebbert <cebbert.lkml@...il.com> wrote:
> 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.
..
>
> 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.

EINVAL does seem a suitable return value for invalid
combinations of flags, if those are explicitly checked. The
stack does not do this, though. Most flags are simply
ignored. For backward compatibility, this leniency is
likely required.

Previously, EINVAL was returned, but not  because msg_flags
contained an unsupported combination. MSG_OOB happened
to be the first tested flag in the set and happens to return
EINVAL when no urgent data is waiting.

I think applications simply cannot assume a consistent
return value when passing unsupported combinations
of flags. This is undefined behavior.
--
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