linux-kernel - Incorrect handling of descriptors put into UNIX domain sockets?

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

Date:	Sun, 26 Nov 2006 20:46:48 +0100
From:	Jürgen Pabel <jpabel@...aya.de>
To:	linux-kernel@...r.kernel.org
Subject: Incorrect handling of descriptors put into UNIX domain sockets?

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@...aya.de
Internet: http://www.akkaya.de
-
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/