Report Bug to Linux Control Group

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, our team has found a problem in fs system on Linux kernel v5.10,
leading to DoS attacks.



The struct file can be exhausted by normal users by calling multiple
syscalls such as timerfd_create/pipe/open etc. Although the rlimit
limits the max fds could be opened by a single process. A normal user
can fork multiple processes, repeatedly make the
timerfd_create/pipe/open syscalls and exhaust all struct files. As a
result, all struct-file-allocation related operations of all other
users will fail.



In fact, we try this attack inside a deprivileged docker container
without any capabilities. The processes in the docker can exhaust all
struct-file on the host kernel. We use a machine with 16G memory. We
start 2000 processes, each process with a 1024 limit. In total, around
1613400 number struct-file are consumed and there is no available
struct-file in the kernel. The total consumed memory is less than 2G,
which is small, so the memory control group can not help.



They are caused by the code snippets listed below:

/*----------------fs/file_table.c----------------*/

   ......

134 struct file *alloc_empty_file(int flags, const struct cred *cred)

135 {

        ......

142     if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) {

               ......

147            if (percpu_counter_sum_positive(&nr_files) >=
files_stat.max_files)

148                   goto over;

149     }

       ......

157 over:

       ......

163     return ERR_PTR(-ENFILE);

164 }

/*-----------------------------------------------*/

The code at line 147 could be triggered by syscalls
timerfd_create/pipe/open etc. Besides, there are no  Linux control
groups or Linux namespaces that can limit or isolate the struct file
resources. Is there necessary to create a new control group or
namespace to defend against this attack?



Looking forward to your reply!


                                                       Nanzi Yang



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux