netdev - Re: Unix Socket buffer attribution

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

Message-ID: <20130123183553.GA13433@order.stressinduktion.org>
Date:	Wed, 23 Jan 2013 19:35:53 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Yannick Koehler <yannick@...hler.name>
Cc:	netdev@...r.kernel.org
Subject: Re: Unix Socket buffer attribution

On Wed, Jan 23, 2013 at 11:41:16AM -0500, Yannick Koehler wrote:
> I did some more research, I found out that netlink and
> sock_queue_err_skb does the same trick that I claim to be missing
> under the net/unix/af_unix.c.  After adding the code, I got a problem
> since af_unix.c "_recvmsg()" functions assume that the skb->sk is
> holding the peer socket not the current one related to the receive
> skb.  It extract the sun_path name from it.  Since with UDP each
> packet may have a different peer, the only solution I found was to use
> the skb control block to hold the peer name.  The problem is that this
> cb member is 48 bytes in length and sun_path is 108 bytes in size.  So
> I had to increase it from 48 to 160 bytes.
> 
> This obviously increase the cost of an SKB struct, so I do not really
> like this solution. But at least it seems to prove my point and now,
> with this I can have my clients working except the one mis-behaving.
> I am attaching a patch.

Yes, you cannot do that. I would try to place a refcounted pointer to the
original sk in unix_skb_params. Perhaps a refcounted unix_address will dot the
trick, too.

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