Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

Hannes Frederic Sowa [off-list ref] writes:

On Tue, Nov 10, 2015, at 22:55, Rainer Weikusat wrote:

quoted

An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams.

[...]

This whole patch seems pretty complicated to me.

Can't we just remove the unix_recvq_full checks alltogether and unify
unix_dgram_poll with unix_poll?

If we want to be cautious we could simply make unix_max_dgram_qlen limit
the number of skbs which are in flight from a sending socket. The skb
destructor can then decrement this. This seems much simpler.

Would this work?

In the way this is intended to work, cf

http://marc.info/?t=115627606000002&r=1&w=2

only if the limit would also apply to sockets which didn't sent anything
so far. Which means it'll end up in the exact same situation as before:
Sending something using a certain socket may not be possible because of
data sent by other sockets, so either, code trying to send using this
sockets ends up busy-waiting for "space again available" despite it's
trying to use select/ poll/ epolll/ $whatnot to get notified of this
condition and sleep until then or this notification needs to be
propagated to sleeping threads which didn't get to send anything yet.

Hi,

On Wed, Nov 11, 2015, at 17:12, Rainer Weikusat wrote:

Hannes Frederic Sowa [off-list ref] writes:

quoted

On Tue, Nov 10, 2015, at 22:55, Rainer Weikusat wrote:

quoted

An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams.

[...]

quoted

This whole patch seems pretty complicated to me.

Can't we just remove the unix_recvq_full checks alltogether and unify
unix_dgram_poll with unix_poll?

If we want to be cautious we could simply make unix_max_dgram_qlen limit
the number of skbs which are in flight from a sending socket. The skb
destructor can then decrement this. This seems much simpler.

Would this work?

In the way this is intended to work, cf

http://marc.info/?t=115627606000002&r=1&w=2

Oh, I see, we don't limit closed but still referenced sockets. This
actually makes sense on how fd handling is implemented, just as a range
check.

Have you checked if we can somehow deregister the socket in the poll
event framework? You wrote that it does not provide such a function but
maybe it would be easy to add?

Thanks,
Hannes