mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Menage <pmenage@ensim.com>
To: linux-kernel@vger.kernel.org
Cc: torvalds@transmeta.com, Jan Kara <jack@suse.cz>, alan@redhat.com
Cc: pmenage@ensim.com
Subject: [PATCH] Inode quota allocation loophole (2.4)
Date: Tue, 12 Jun 2001 01:13:36 -0700	[thread overview]
Message-ID: <E159jIv-0004W5-00@pmenage-dt.ensim.com> (raw)


Currently, dquot_initialize() is a no-op if the inode being initialized
isn't a regular file, directory or symlink. This means that calling
DQUOT_ALLOC_INODE() on a named pipe or AF_UNIX socket has no effect (the
same applies to devices, but this is less likely to be a problem as
random users can't create them); as a result a user can exhaust the
filesystem's inodes even when they have a quota limit. This problem is
exploitable in 2.2.19 and 2.4.2, and appears to be present in all kernel
versions that I've looked at.

I presume that the reason for not putting quotas on pipes and sockets is
that it's slightly more efficient not to do so. If that's the case, then
the simplest solution would be to remove the checks in fs/dquot.c (patch
below for 2.4.5 - patch for 2.2 in following email). Are there any
undesirable consequences to pipes, sockets and devices having non-NULL
pointers in i_dquot[]?

Paul


--- linux/fs/dquot.c	Sun May 20 11:32:11 2001
+++ linux.new/fs/dquot.c	Tue Jun 12 00:39:50 2001
@@ -651,8 +651,6 @@
 {
 	int cnt;
 
-        if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode)))
-                return 0;
 	if (is_quotafile(inode))
 		return 0;
 	if (type != -1)
@@ -1022,9 +1020,6 @@
 	unsigned int id = 0;
 	short cnt;
 
-	if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode) &&
-            !S_ISLNK(inode->i_mode))
-		return;
 	lock_kernel();
 	/* We don't want to have quotas on quota files - nasty deadlocks possible */
 	if (is_quotafile(inode)) {








             reply	other threads:[~2001-06-12  8:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-12  8:13 Paul Menage [this message]
2001-06-12 23:00 ` Jan Kara

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=E159jIv-0004W5-00@pmenage-dt.ensim.com \
    --to=pmenage@ensim.com \
    --cc=alan@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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

all inboxes | Powered by JetHome®