netdev - Re: bug in passing file descriptors

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5253061A.7060701@nec-labs.com>
Date:	Mon, 7 Oct 2013 15:06:02 -0400
From:	Steve Rago <sar@...-labs.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Network Development <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Michael Kerrisk-manpages <mtk.manpages@...il.com>,
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: bug in passing file descriptors

On 10/07/2013 02:44 PM, Andy Lutomirski wrote:
>
> ISTM that, in order for further cmsgs to be correctly decoded, all of
> the relevant things need to match.
>
> put_cmsg uses this layout: cmsghdr, padding, payload, padding.
> CMSG_SPACE matches that calculation.
>
> scm_detach_fds is the actual code path for SCM_RIGHTS.  It does the same thing.
>
> CMSG_DATA also things that there's possible padding after cmsghdr.
>
> So I think everything's okay.
>
> --Andy
>

Maybe.  So a client expecting to receive x bytes of control information should make sure their buffer is at least 
CMSG_SPACE(x) bytes long instead of CMSG_LEN(x) bytes long, because you feel compelled to copy the final padding from 
kernel space to user space?  Seems wrong to me.  IMHO, the final padding should only come into play when calculating 
where the next header should begin.

Steve

--
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