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: <200702061355.39660.daniel.kabs@mobotix.com>
Date:	Tue, 6 Feb 2007 13:55:39 +0100
From:	Daniel Kabs <daniel.kabs@...otix.com>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC

On Monday 05 February 2007 01:52, David Miller wrote:
> > Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect
> > message truncation due to insufficient buffer size.
>
> What part of "Only valid for packet sockets" from the manual page
> escapes you?  :-))
> It's a feature which only was meant to be valid for AF_PACKET sockets.

Thanks for pointing that out. I thought, "packet sockets" means  
"datagram-oriented  socket". Obviously it means PF_PACKET instead. It's 
hard to learn programming IPC by only reading man pages :-)

> What UDP is doing is different, it's returning the full packet length
> when the packet is larger then the given buffer size, but it does this
> irregardless of whether you set MSG_TRUNC in the recvmsg() passed-in
> flags.  UDP itself sets the MSG_TRUNC flag when it detects this
> situation.

Please correct me gently if I am wrong: According to the kernel source 
code, this behaviour was introduced with patch-2.6.8: 

http://www.kernel.org/diff/diffview.cgi?file=/pub/linux/kernel/v2.6/patch-2.6.8.gz;z=4325

linux/net/ipv4/udp.c 
+
         err = copied;
+        if (flags & MSG_TRUNC)
+          err = skb->len - sizeof(struct udphdr);

I think local sockets (PF_UNIX) implement a different semantics: According 
to unix_dgram_recvmsg() in linux/net/unix/af_unix.c, in case of 
truncation the buffer size is returned and not the full packet length.

In my opinion this implementation of local sockets (PF_UNIX) is not 
following the wording of the man page man 2 recv: "These  calls  return  
the  number of bytes received". Am I getting something wrong here?

Why not improve consistency and make unix_dgram_recvmsg() return the full 
packet length? So it would behave as UDP does. What do you think about 
adding the following code to linux/net/unix/af_unix.c:
        err = size;
+        if (flags & MSG_TRUNC)
+                err = skb->len;


Cheers
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ