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

Message-ID: <MDEHLPKNGKAHNMBLJOLKCEHGGLAC.davids@webmaster.com>
Date:	Tue, 11 Sep 2007 02:27:24 -0700
From:	"David Schwartz" <davids@...master.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.

So then there is no reason there should be any problem if the packets are
fed after the socket is destroyed. I would try to figure out why something
that should not give you a problem is giving you a 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.

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

So what exactly goes wrong then? This approach sounds bulletproof.

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/