01 Jan, 2006

1 commit

  • This is a slightly more complete fix for the previous minimal sysctl
    string fix. It always terminates the returned string with a NUL, even
    if the full result wouldn't fit in the user-supplied buffer.

    The returned length is the full untruncated length, so that you can
    tell when truncation has occurred.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

31 Dec, 2005

2 commits

  • For the sysctl syscall, if the user wants to get the old value of a
    sysctl entry and set a new value for it in the same syscall, the old
    value is always overwritten by the new value if the sysctl entry is of
    string type and if the user sets its strategy to sysctl_string. This
    issue lies in the strategy being run twice if the strategy is set to
    sysctl_string, the general strategy sysctl_string always returns 0 if
    success.

    Such strategy routines as sysctl_jiffies and sysctl_jiffies_ms return 1
    because they do read and write for the sysctl entry.

    The strategy routine sysctl_string return 0 although it actually read
    and write the sysctl entry.

    According to my analysis, if a strategy routine do read and write, it
    should return 1, if it just does some necessary check but not read and
    write, it should return 0, for example sysctl_intvec.

    Signed-off-by: Yi Yang
    Signed-off-by: Linus Torvalds

    Yi Yang
     
  • If the string was too long to fit in the user-supplied buffer,
    the sysctl layer would zero-terminate it by writing past the
    end of the buffer. Don't do that.

    Noticed by Yi Yang

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

09 Nov, 2005

1 commit

  • You could open the /proc/sys/net/ipv4/conf// file, then
    wait for interface to go away, try to grab as much memory as possible in
    hope to hit the (kfreed) ctl_table. Then fill it with pointers to your
    function. Then do read from file you've opened and if you are lucky,
    you'll get it called as ->proc_handler() in kernel mode.

    So this is at least an Oops and possibly more. It does depend on an
    interface going away though, so less of a security risk than it would
    otherwise be.

    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Linus Torvalds

    Al Viro
     

07 Nov, 2005

2 commits

  • Various core kernel-doc cleanups:
    - add missing function parameters in ipc, irq/manage, kernel/sys,
    kernel/sysctl, and mm/slab;
    - move description to just above function for kernel_restart()

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • AIO was adding a new context's max requests to the global total before
    testing if that resulting total was over the global limit. This let
    innocent tasks get their new limit tested along with a racing guilty task
    that was crossing the limit. This serializes the _nr accounting with a
    spinlock It also switches to using unsigned long for the global totals.
    Individual contexts are still limited to an unsigned int's worth of
    requests by the syscall interface.

    The problem and fix were verified with a simple program that spun creating
    and destroying a context while holding on to another long lived context.
    Before the patch a task creating a tiny context could get a spurious EAGAIN
    if it raced with a task creating a very large context that overran the
    limit.

    Signed-off-by: Zach Brown
    Cc: Benjamin LaHaise
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zach Brown
     

30 Aug, 2005

1 commit

  • Of this type, mostly:

    CHECK net/ipv6/netfilter.c
    net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
    net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

28 Jul, 2005

1 commit

  • Split spin lock and r/w lock implementation into a single try which is done
    inline and an out of line function that repeatedly tries to get the lock
    before doing the cpu_relax(). Add a system control to set the number of
    retries before a cpu is yielded.

    The reason for the spin lock retry is that the diagnose 0x44 that is used to
    give up the virtual cpu is quite expensive. For spin locks that are held only
    for a short period of time the costs of the diagnoses outweights the savings
    for spin locks that are held for a longer timer. The default retry count is
    1000.

    Signed-off-by: Martin Schwidefsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Martin Schwidefsky
     

14 Jul, 2005

1 commit


13 Jul, 2005

1 commit

  • inotify is intended to correct the deficiencies of dnotify, particularly
    its inability to scale and its terrible user interface:

    * dnotify requires the opening of one fd per each directory
    that you intend to watch. This quickly results in too many
    open files and pins removable media, preventing unmount.
    * dnotify is directory-based. You only learn about changes to
    directories. Sure, a change to a file in a directory affects
    the directory, but you are then forced to keep a cache of
    stat structures.
    * dnotify's interface to user-space is awful. Signals?

    inotify provides a more usable, simple, powerful solution to file change
    notification:

    * inotify's interface is a system call that returns a fd, not SIGIO.
    You get a single fd, which is select()-able.
    * inotify has an event that says "the filesystem that the item
    you were watching is on was unmounted."
    * inotify can watch directories or files.

    Inotify is currently used by Beagle (a desktop search infrastructure),
    Gamin (a FAM replacement), and other projects.

    See Documentation/filesystems/inotify.txt.

    Signed-off-by: Robert Love
    Cc: John McCutchan
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert Love
     

26 Jun, 2005

1 commit


24 Jun, 2005

1 commit

  • Add a new `suid_dumpable' sysctl:

    This value can be used to query and set the core dump mode for setuid
    or otherwise protected/tainted binaries. The modes are

    0 - (default) - traditional behaviour. Any process which has changed
    privilege levels or is execute only will not be dumped

    1 - (debug) - all processes dump core when possible. The core dump is
    owned by the current user and no security is applied. This is intended
    for system debugging situations only. Ptrace is unchecked.

    2 - (suidsafe) - any binary which normally would not be dumped is dumped
    readable by root only. This allows the end user to remove such a dump but
    not access it directly. For security reasons core dumps in this mode will
    not overwrite one another or other files. This mode is appropriate when
    adminstrators are attempting to debug problems in a normal environment.

    (akpm:

    > > +EXPORT_SYMBOL(suid_dumpable);
    >
    > EXPORT_SYMBOL_GPL?

    No problem to me.

    > > if (current->euid == current->uid && current->egid == current->gid)
    > > current->mm->dumpable = 1;
    >
    > Should this be SUID_DUMP_USER?

    Actually the feedback I had from last time was that the SUID_ defines
    should go because its clearer to follow the numbers. They can go
    everywhere (and there are lots of places where dumpable is tested/used
    as a bool in untouched code)

    > Maybe this should be renamed to `dump_policy' or something. Doing that
    > would help us catch any code which isn't using the #defines, too.

    Fair comment. The patch was designed to be easy to maintain for Red Hat
    rather than for merging. Changing that field would create a gigantic
    diff because it is used all over the place.

    )

    Signed-off-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

01 May, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds