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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 11 Sep 2007 16:38:06 +0800
From:	"Alvin Valera" <alvinvalera@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Socket owner problem?

Hi David,

Thanks for your quick reply.

> If that were true, anyone who could send those packets to your machine would
> be able to cause the system to hang too.

You're right to say that :)

> Perhaps you are feeding the packets
> back in at too high a layer.

Not really. In fact, I pass the packet back to the "lower layer" again
by calling netif_receive_skb(). Note that packets can go in a loop
here. To avoid queuing the same packets repeatedly, the module "marks"
them the first time they are queued. Marked packets are simply
NF_ACCEPT'ed by the module hook and therefore are propagated up the
netfilter chain.

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

The queue is not associated with the socket. It is independent and is
meant just for the module to use for queuing packets that are supposed
to be delayed. But for each packet in this queue, there is an
associated kernel timer. Once this timer expires, the associated
packet is fed into the netif_receive_skb().

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