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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Solar Designer <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: [email protected] (Alex Riesen)
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Solar Designer <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Alan Cox <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Willy Tarreau <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Alan Cox <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Willy Tarreau <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Alan Cox <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Willy Tarreau <[email protected]>
  • Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
    • From: Alan Cox <[email protected]>

• Prev by Date: Re: [Patch] Signedness issue in drivers/net/phy/phy_device.c
• Next by Date: Possible deadlock in videobuf_dma_init_user
• Previous by thread: Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
• Next by thread: Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]