linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: 杨男子 <nzyang@stu.xidian.edu.cn>
Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	security@kernel.org
Subject: Re: Report Bug to Linux File System about fs/devpts
Date: Sun, 5 Sep 2021 19:20:01 +0200	[thread overview]
Message-ID: <YTT8QQqQ2n63OVSP@kroah.com> (raw)
In-Reply-To: <2f73b89f.266.17bb4a7478b.Coremail.nzyang@stu.xidian.edu.cn>

On Sun, Sep 05, 2021 at 02:31:06PM +0800, 杨男子 wrote:
> Hi, our team has found a problem in fs system on Linux kernel v5.10, leading to DoS attacks.
> 
> The pseudo-terminals can be opened by normal user can be exhausted by one singal normal user by calling syscall such as open. A normal user keeps opening/dev/ptmx to trigger ptmx_open, which calls devpts_new_index and increases pty_count. In a couple of seconds, the pty_count limit is reached, and other normal user’s ptmx_open operations fail.
> 
> In fact, we try this attack inside a deprivileged docker container without any capabilities. The processes in the docker can exhaust all normal user’s pseudo-terminals on the host kernel. We use a machine with 16G memory. We start 4 processes to open /dev/ptmx repeatedly. In total, around 3072 number of pseudo-terminals are consumed and other normal user can not use pseudo-terminals. 

If you are concerned about this, please restrict the kernel.pty.max
value to be much lower.  Otherwise, do not run untrusted code in a
container and expect it to not be able to use up system resources :)

All of these "reports" you sent out today, seem to imply that you feel
that containers should never be allowed to take up resources from things
in other containers or elsewhere on the system.  As has been pointed
out, that is possible, but you need to tune your system to keep that
from happening by using one of the many various resource limit "knobs"
that are available to you.

These are not kernel bugs, but rather system configuration issues in
userspace from what I can determine.

thanks,

greg k-h

  reply	other threads:[~2021-09-05 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05  6:31 Report Bug to Linux File System about fs/devpts 杨男子
2021-09-05 17:20 ` Greg KH [this message]
2021-09-06  1:36   ` Theodore Ts'o
2021-09-06  9:01     ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YTT8QQqQ2n63OVSP@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nzyang@stu.xidian.edu.cn \
    --cc=security@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).