Why should a user program mess with kernel space?

I’m not even sure what the problem is, but I’m talking about the kernel attack described here. Down this list of comments somebody asked about renicing the process. The trick didn’t improve the situation (the machine still runs in a very sluggish fashion) and the replying comment says something about kernel space vs user space.

First of, is the replying comment correct? If so, why does renice work for things in user space and not for things in kernel space? Also, according to what I read, all programs that a user starts emself should be in user space, what did I miss?

If it is incorrect, then why doesn’t renice improve the situation?

Asked By: phunehehe


There are services a kernel provides to user-space (such as opening sockets). There is a well-defined interface (API) that user-space programs can interact with the kernel through.

In this case, the user-space program is repeatedly opening sockets and sending file descriptors through them, then closing the sockets. These actions are performed by the kernel. It will hold the file descriptor in a buffer until the other end of the socket reads it. The particular bug is that a garbage collector should eventually free the file descriptor, but it doesn’t – the fd gets leaked. The leaked fds add up and sit there consuming resources. Killing the program doesn’t free the resources because they are not owned by the program.

Answered By: Shawn J. Goff
Categories: Answers Tags:
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.