Incorrect handling of descriptors put into UNIX domain sockets?

[Jürgen Pabel]

Hi all,

I may have stumbled upon a bug (or is it a feature?). First off though,
I am reporting this based on my recollection - so my description might
not be 100% accurate (this happened about two months ago). Since I don't
have time to set up a verification scenario, I figured I'd just report
this and let some else do the grunt work (thank you) or just not worry
about it.

The problem (on a SLES9 - which is something like 2.6.5 plus SuSE
patches) was that a file descriptor, once put into a UNIX domain socket
would not be considered by the kernel when the according resource was
being closed. If the handle was taken "out of the UDS" after the
resource already has been closed than the handle appeared to represent a
resource that was no longer valid. What that would do if you actually
used the handle is entirely left untested.

Essentially what I observed was that the handle represented a TCP
hashtable entry that was no longer allocated in the kernel, but was
nevertheless "given" to the process. Technically speaking: "lsof"
reported a socket identifier not listed in /proc/net/tcp anymore (this
was double and triple checked at the time because it seemed so odd).

The process now appeared to have a handle to a TCP connection which was
no longer established. My assumption here is that the handle would
actually match the next connection that has the same TCP identity (IP
addresses/ports) and might "work" with that connection.

jp

-- 
Jürgen Pabel, CISSP

Akkaya Consulting GmbH
Eupener Straße 137
50933 Köln

Telefon: +49 221 9473007
Telefax: +49 221 4911970
Mobil:   +49 160 8806134

E-Mail:  jpabel@xxxxxxxxx
Internet: http://www.akkaya.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/