| 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
| ||
|
Message-ID: <8d33dcd40709110138h1bee46d2x8521f5b8f0d3a955@mail.gmail.com> 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/
Powered by blists - more mailing lists