[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 1622 (linux mm)] New - Incoherent Count of Users of Task Substructures and Direct Memory Access Bugs in 2.4.2



http://distro.conectiva.com.br/bugzilla/show_bug.cgi?id=1622

           Summary: Incoherent Count of Users of Task Substructures and
                    Direct Memory Access Bugs in 2.4.2
           Product: Linux kernel MM
           Version: 2.4 (stable)
          Platform: All
               URL:
        OS/Version: Linux
            Status: UNCONFIRMED
 Status Whiteboard:
          Keywords:
        Resolution:
          Severity: critical
          Priority: P3
         Component: linux mm
        AssignedTo: linux-mm-bugs@nl.linux.org
        ReportedBy: moshe@moelabs.com


Bug 1
-----

Direct access to user-memory from kernel:

The routines "proc_write_register" and "proc_write_status"
of "fs/binfmt_misc.c" wrongly access the "buffer" argument which is in
user-space: this is of course not allowed and could cause a kernel-fault
if the supplied address is invalid.

I have a patch fixing this problem. 


Bug 2
-----


Incoherent count of users of task sub-structures:

Several per-process sub-structures have an atomic "count" field, indicating
the number of references to the structure, so that the last user deallocates
the structure.  This field is often incremented by casual lookers, especially
via the /proc file-system, and therefore does not truly represent the number
of tasks actually sharing the structure as clones - however, for at least
some of those structures, some kernel code wrongly uses the counts in that
manner.

"fs_struct" and "file_struct":
------------------------------
The security checks in "compute_creds" of "fs/exec.c", lines 687-688,
assume that "count" refers to the number of clone-processes using the
structures, whereas it may also include onlookers via "/proc":
as a result, the "exec" system-call could fail unnecessarily.  In fact,
this bug could even be used by a hacker, using /proc to cause processes
of other users to fail.
The solution is to add another atomic field, say "users", to count only
processes that actually use the structure as clones.

Solution: an extra counter, "clones" was added to both structures.

mm_struct:
----------
the "mm_struct" already has both "mm_count" and "mm_users", but neither of
them properly conveys the real number of users as "mm_users" is also
incremented by "ptrace", "vmscan" and various /proc functions.
One outcome, for example, is that a process may randomly fail to produce a
core-dump just, for example, because pages happen to be swapped-out at the time,
or because some other user is running "ps" or "top".
this is because the code in "do_coredump" of "fs/exec.c" looks at "mm_users".
Also, in "write_ldt" of "arch/i386/kernel/ldt.c", a confusing warning message
may be unnecessarily displayed on the console, again just because someone
happened to run "ps" or "top" at a crucial moment.

Solution: a third counter, "mm_clones" was added.


======================
The "count" field of the "signal_struct" appears to be safe - for the time
being (unless it became possible to watch a process' signal-disposition via
/proc or "ptrace").

The patch for Bug 2, is available, too. 

Please try out both patches and let me know if they work for you as well as 
they did for me on SMP i386 2.4.2

The patches are at www.moelabs.com/patch01_23 and www.moelabs.com/patch01_24


Kind regards

Moshe Bar
www.moelabs.com
-
Linux-mm-bugs:  bugzilla list for the Linux-MM subsystem
Archive:        http://mail.nl.linux.org/linux-mm-bugs/
Web site:       http://www.linux.eu.org/Linux-MM/
Development:    linux-mm@kvack.org