Björn Persson <bjorn <at> xn--rombobjrn-67a.se> writes: > > JB wrote: > > This does not help in this case. The attack's effect can happen at any time > > and catch systemd with its pants down at any time in the scenarios you > > described. > > The attack is on socket buffer availability via kernel, it lasts until no > > resource is available system-wide. At that point systemd or any other > > socket-based communication is brought to a standstill. > > The point is, systemd can not be stopped, or restarted/reinitialized/reset > > as any other stand-alone service daemon relying on sockets availability > > manually. > > The process #1, the GOD of all processes, is incapacitated, for good. > > I searched for "attack" and "socket buffer availability" trying to find out > what kind of attack you're talking about. Duckduckgo had never heard about > it. > Google gave me three hits, and all three were your previous message in this > list. It would help if you could explain how this attack works and how > exactly it would cause SystemD to lock up. > > Is it perchance a syn flood you're talking about? If so, we have a good > defense since ages. It's known as syn cookies. > > Björn Persson > > The link is in one of my posts above, but here it is again: http://www.securiteam.com/unixfocus/6U00P1PEVQ.html It contains a detailed description and the original CVE link. Once again, it is about DOS of a resource in question, that is a socket buffer memory, with system-wide effect, obviously on any socket-based process. JB -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
