linux-kernel - Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060820191722.GQ602@1wt.eu>
Date:	Sun, 20 Aug 2006 21:17:22 +0200
From:	Willy Tarreau <w@....eu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Solar Designer <solar@...nwall.com>,
	Alex Riesen <fork0@...rs.sourceforge.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits

On Sun, Aug 20, 2006 at 08:33:27PM +0100, Alan Cox wrote:
> Ar Sul, 2006-08-20 am 21:01 +0200, ysgrifennodd Willy Tarreau:
> > 2.4 has no printk_ratelimit() function and I'm not sure it's worth adding
> > one for only this user. One could argue that once it's implemented, we can
> > uncomment some other warnings that are currently disabled due to lack of
> > ratelimit.
> 
> Agreed. But if it isnt ratelimited then people will be able to use it
> flush other "interesting" log messages out of existance...
> 
> > 
> > In this special case (set*uid), the only reason we might fail is because
> > kmem_cache_alloc(uid_cachep, SLAB_KERNEL) would return NULL. Do you think
> > it could intentionnally be tricked into failing, or that under OOM we might
> > bother about the excess of messages ?
> > 
> > If so I can backport the printk_ratelimit() function, I would just like an
> > advice on this.
> 
> If there are multiple potential users then a backport might be sensible

Ok, I will proceed that way then. I see at least two places in binfmt_elf :

   631                  if ((interpreter_type & INTERPRETER_ELF) &&
   632                       interpreter_type != INTERPRETER_ELF) {
   633                          // FIXME - ratelimit this before re-enabling
   634                          // printk(KERN_WARNING "ELF: Ambiguous type, using ELF\n");
   635                          interpreter_type = INTERPRETER_ELF;
   636                  }


   824                  if (BAD_ADDR(elf_entry)) {
   825                          printk(KERN_ERR "Unable to load interpreter %.128s\n",
   826                                  elf_interpreter);
   827                          force_sig(SIGSEGV, current);
   828                          retval = IS_ERR((void *)elf_entry) ? PTR_ERR((void *)elf_entry) : -ENOEXEC;
   829                          goto out_free_dentry;
   830                  }

The first one might be interesting, while the second one should definitely
be ratelimited or removed.

Thanks,
willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/