Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: [patch] af_unix fix for a panic a DoS and a memory leak [Re: | Date | Tue, 2 Mar 1999 21:25:00 +0300 (MSK) |
| |
Hello!
> >I see... but what to do then? We did not remove syn skb and not yet > > What do you mean with "what to do then"? > > Excuse but my bad English is hurting my understanding again.
It is my bad English. I wanted to say, that I understood the problem, dazed, confused and have to think.
Next my mail and mail from Al explains more.
The situation is really weird. The problem of wrong resource accounting on unix sockets is well-known flaw, but I understood that it is fatal only now.
F.e. the simplest example is datagram socket. We account for sent skbs on sender. I considered it as security problem, f.e. client asks keyserver, server replies but client does not read reply. Then client repeats this until sndbuf of keyserv overflows. Finita: keyserver is blocked forever.
But I missed even worse thing: this guy could make:
for(;;) { s = socket(PF_UNIX, SOCK_DGRAM, 0); sendto(s, some service, its sndbuf); close(s); }
Essentially, operation of connect on SOCK_STREAM is equivalent.
It means, that solution is either moving flow control to receiver side or keeping queues on sender side. It is final solution, but it requires serious rewrite of af_unix.c. We did not it at the beginning of 2.1, when the problem was understood, and it is too late to make it now. In fact, it was the reason, why af_netlink was written from scratch: it uses receiver based flow control.
What can we make now?
The first guess is to limit total number of unix sockets (both alive and dead) to max_files/2. Then one process still may eat all of them. I still have no answer.
With stream sockets we could kill orderly release semantics and to purge data on close, with some ugly fixes in select(),accept() to avoid random blocking. Hmm... it is not clear, how missing orderly release will affect apps. connect(),write(),close() is really used sometimes. And it does not solve problem with datagram sockets.
Well, let's not fall to panic yet 8) I do not remember cases, when thinking did help 8)
Alexey
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |