linux-kernel - RE: Socket owner problem?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKGEHAGLAC.davids@webmaster.com>
Date:	Tue, 11 Sep 2007 01:01:07 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<linux-kernel@...r.kernel.org>
Subject: RE: Socket owner problem?

> The problem happens like this:
> Once the socket is closed by the user-space application, there are
> still packets left in the module's queue. Now, the moment the kernel
> timer expires and the module propagates those packets up into the
> higher layer, the system hangs.

If that were true, anyone who could send those packets to your machine would
be able to cause the system to hang too. Perhaps you are feeding the packets
back in at too high a layer.

> I've been searching for ways to determine if associated socket is
> closed. This way, if my module knows that the user-space already
> closed the socket, it will not propagate the packet up. Does anyone
> have a solution for this problem?

What object is this queue logically associated with? If the socket, you
should probably hook 'release' so you can purge the queue when the socket is
removed.

DS

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