Re: Change proc file permissions with sysctls

2005-03-20 Thread Jan Engelhardt
 The permissions of files in /proc/1 (usually belonging to init) are
 kept as they are.  The idea is to let system processes be freely
 visible by anyone, just as before.  Especially interesting in this
 regard would be instances of login.  I don't know how to easily
 discriminate between system processes and normal processes inside
 the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
 Any ideas?

As a side note, I have not experienced any problems when also hiding system 
processes by making e.g. /proc/1 mode 0700.



Jan Engelhardt
-- 
-
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/


[PATCH][0/6] Change proc file permissions with sysctls

2005-03-19 Thread Rene Scharfe
The following patches implement another interface that allows an admin
to restrict permissions inside /proc/pid to enhance the privacy of
users.  Following a suggestion by Albert Calahan this set of patches
introduces five sysctls, each one changes the permissions of a certain
file in /proc/pid.

It works by implementing getattr and permission methods that update the
files' permissions (btw. Al Viro suggested doing it this way right from
the start..).

To cloak as much as currently possible:

   # sysctl -q proc.cmdline=0400
   # sysctl -q proc.maps=0400
   # sysctl -q proc.stat=0400
   # sysctl -q proc.statm=0400
   # sysctl -q proc.status=0400

This will set the permissions of /proc/*/cmdline etc. to the given
value.

The permissions of files in /proc/1 (usually belonging to init) are
kept as they are.  The idea is to let system processes be freely
visible by anyone, just as before.  Especially interesting in this
regard would be instances of login.  I don't know how to easily
discriminate between system processes and normal processes inside
the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
Any ideas?

It's easy to make more files' permissions configurable, if the need
arises.

This implementation is a lot bigger than the quick hacks I sent earlier.
Is this feature growing too fat?  Also I'm unsure about the #ifdef'ery
in fs/proc/base.c, I just wanted to be consistent with the surrounding
code. :-P

Rene

-
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/


Re: [PATCH][0/6] Change proc file permissions with sysctls

2005-03-19 Thread Albert Cahalan
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:

 The permissions of files in /proc/1 (usually belonging to init) are
 kept as they are.  The idea is to let system processes be freely
 visible by anyone, just as before.  Especially interesting in this
 regard would be instances of login.  I don't know how to easily
 discriminate between system processes and normal processes inside
 the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
 Any ideas?

The ideal would be to allow viewing:

1. killable processes (that is, YOU can kill them)
2. processes sharing a tty with a killable process

Optionally, add:

3. processes controlling a tty master of a killable process
4. ancestors of all of the above
5. children of killable processes

This is of course expensive, but maybe you can get some of
it cheaply. For example, allow viewing a process if the session
leader, group leader, parent, or tpgid process is killable.


-
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/


Re: [RFC][PATCH] Simple privacy enhancement for /proc/pid

2005-04-12 Thread Albert Cahalan
On Sun, 2005-04-10 at 17:38 +0200, Rene Scharfe wrote:

 Albert, allowing access based on tty sounds nice, but it _is_ expansive.
 More importantly, perhaps, it would virtualize /proc: every user would
 see different permissions for certain files in there.  That's too comlex
 for my taste.

If you really can't allow access based on tty, then at least allow
access if any UID value matches any UID value. Without this, a user
can not always see a setuid program they are running.

 First, configuring via kernel parameters is sufficient.  It simplifies
 implementation a lot because we know the settings cannot change.  And we
 don't need the added flexibility of sysctls anyway -- I assume these
 parameters are set at installation time and never touched again.

This means mucking with boot parameters, which can be a pain.
The various boot loaders do not all use the same config file.

 Then I suppose we don't need to be able to fine-tune the permissions for
 each file in /proc/pid/.  All that we need is a distinction between
 normal users (which are to be restricted) and admins (which need to
 see everything).

The /proc/*/maps file sure is different from the /proc/*/status file.
The same for all the others, really.

 This patch introduces two kernel parameters: proc.privacy and proc.gid.
 The group ID attribute of all files below /proc/pid is set to
 proc.gid, but only if you activate the feature by setting proc.privacy
 to a non-zero value.

This is very bad. Please do not change the GID as seen by
the stat() call. This value is used.


-
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/


[PATCH 2/2] Documentation: describe /proc//userns_counts

2016-08-15 Thread Andrei Vagin
From: Kirill Kolyshkin <k...@openvz.org>

This file provides current usage of user namespace counters.

Signed-off-by: Kirill Kolyshkin <k...@openvz.org>
Signed-off-by: Andrei Vagin <ava...@openvz.org>
---
 Documentation/filesystems/proc.txt | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index 68080ad..7300d9c 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -44,6 +44,7 @@ Table of Contents
   3.8   /proc//fdinfo/ - Information about opened file
   3.9   /proc//map_files - Information about memory mapped files
   3.10  /proc//timerslack_ns - Task timerslack value
+  3.11  /proc//userns_counts - User namespace counters
 
   4Configuring procfs
   4.1  Mount options
@@ -1889,6 +1890,35 @@ Valid values are from 0 - ULLONG_MAX
 An application setting the value must have PTRACE_MODE_ATTACH_FSCREDS level
 permissions on the task specified to change its timerslack_ns value.
 
+3.11 /proc//userns_counts - User namespace counters
+-
+
+This file provides current usage of user namespace counters.
+
+User namespace counters is a feature that allows to limit the number of various
+kernel objects a user can create. These limits are set via /proc/sys/user/
+sysctls on a per user namespace basis and are applicable to all users in that
+namespace. Therefore, the limits are the same for every user in a user
+namespace.
+
+Each user has their own set of user namespace counters. Once a user creates a
+new user namespace, every new object created inside that namespace is also
+charged to the user. That means that a user is limited by their user namespace
+limits, as well as the limits in their parent user namespaces.
+
+  > cat /proc/813/userns_counts
+  user_namespaces  101000   1
+  pid_namespaces   101000   1
+  ipc_namespaces   101000   4
+  net_namespaces   101000   2
+  mnt_namespaces   101000   5
+  mnt_namespaces   10   1
+
+The meanings of the columns are as follows, from left to right:
+
+  Name Object name
+  UID  User ID
+  UsageCurrent usage
 
 --
 Configuring procfs
-- 
2.5.5



Re: [PATCH][0/6] Change proc file permissions with sysctls

2005-03-19 Thread Bodo Eggert
On Sun, 20 Mar 2005, Rene Scharfe wrote:

 The permissions of files in /proc/1 (usually belonging to init) are
 kept as they are.  The idea is to let system processes be freely
 visible by anyone, just as before.  Especially interesting in this
 regard would be instances of login.

I think you mean login shells, the login process is just the thing asking
for the password agter the (m)ingetty got the username. These processes
are usurally created with the '-' sign in argv[0][0], but the users may
replace that string at will. I think it's still OK to depend on that if
you want a semi-secure system.

  I don't know how to easily
 discriminate between system processes and normal processes inside
 the kernel (apart from pid

Do you mean ppid?

 == 1 and uid == 0 (which is too broad)).
 Any ideas?

This feature seems to be frequently requested. I don't remember the 
outcome, though.

From a quick view, it seems the symlinks in /proc are empty for kernel 
threads and non-empty for user processes. Since you're messing with the 
proc entries, this could be a cheap way to find the kernel threads.
Another possibility is by looking at the blocked signals, signal 9 may not 
be blocked by mortals.

For the system daemons, you could additionally check for the absence of a 
controlling tty, but that's still no safe distinction from a process run 
by nohup. Checking for sid=pid will filter additional processes, but it 
the shell in midnight commander and screen are still false positives.
Checking for */sbin*/ in $PID/command will fail as soon as the daemon 
overwrites argv[0].

I don't think there is a relaible way to tell the system service daemons
from screen except for the name, and you'll want to detect screen-alike
programs, too.

-- 
Top 100 things you don't want the sysadmin to say:
40. The sprinkler system isn't supposed to leak is it?

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
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/


[RFC][PATCH] Simple privacy enhancement for /proc/pid

2005-04-10 Thread Rene Scharfe
Hi all,

sorry it took me so long before offering another patch for restricting
/proc permissions.  Real life kept on intervening.

Albert, allowing access based on tty sounds nice, but it _is_ expansive.
More importantly, perhaps, it would virtualize /proc: every user would
see different permissions for certain files in there.  That's too comlex
for my taste.

My previous patchset was complex, too, given its simple purpose: to
restrict regular users from spying on each other.  So let's cut out what
we don't really need.

First, configuring via kernel parameters is sufficient.  It simplifies
implementation a lot because we know the settings cannot change.  And we
don't need the added flexibility of sysctls anyway -- I assume these
parameters are set at installation time and never touched again.

Then I suppose we don't need to be able to fine-tune the permissions for
each file in /proc/pid/.  All that we need is a distinction between
normal users (which are to be restricted) and admins (which need to
see everything).

In a previous mail I asked how to identify tasks every user should be
able to see details of.  Bodo came up with some nice ideas, like
checking if parent is init(1) to catch daemons and identifying kernel
threads by their unique ability to block SIGKILL.  That's simple and
catches most interesting processes; it fails to catch the children of
forking servers like apache and, notably, sshd, however.

I have another idea: let's keep the details of _every_ process owned by
user root readable by anyone.  The superuser doesn't deserve privacy.
No new hole is opened, as root's files don't change their permissions.
Admittedly, admins are people, too, and they can get privacy, too -- but
only if they use their own regular user ID.  They should be doing that
anyway.

This catches the _important_ processes, those used to provide logins
(and then some :-).  Tools like w, who and pstree keep on working just
fine, even for SSH logins.

This patch introduces two kernel parameters: proc.privacy and proc.gid.
The group ID attribute of all files below /proc/pid is set to
proc.gid, but only if you activate the feature by setting proc.privacy
to a non-zero value.  1 means to allow all users to see root's process
details and hide everyone else's (as described above), 2 gives you the
shared nothing semantics where even root's processes are cloaked.

Patch is against 2.6.12-rc2-mm2, please give it a try and tell me how
you like it.

Thanks,
Rene



diff -pur l1/Documentation/kernel-parameters.txt 
l2/Documentation/kernel-parameters.txt
--- l1/Documentation/kernel-parameters.txt  2005-04-07 23:18:36.0 
+0200
+++ l2/Documentation/kernel-parameters.txt  2005-04-10 13:52:56.0 
+0200
@@ -1116,16 +1116,25 @@ running once the system is up.
[ISAPNP] Exclude memory regions for the 
autoconfiguration
Ranges are in pairs (memory base and size).
 
+   processor.max_cstate=   [HW, ACPI]
+   Limit processor to maximum C-state
+   max_cstate=9 overrides any DMI blacklist limit.
+
+   proc.gid=   [KNL] Group ID attribute of the files in /proc/pid,
+   default is 0.  This parameter is ignored if
+   proc.privacy is 0.
+   proc.privacy=   [KNL] Take away permissions for files in /proc/pid
+   from world (think chmod o-rwx) and apply proc.gid
+   setting.  0 = disabled (default), 1 = restrict access
+   to all process details except those having a uid of 0,
+   2 = restrict access to all process details.
+
profile=[KNL] Enable kernel profiling via /proc/profile
{ schedule | number }
(param: schedule - profile schedule points}
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
 
-   processor.max_cstate=   [HW, ACPI]
-   Limit processor to maximum C-state
-   max_cstate=9 overrides any DMI blacklist limit.
-
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
diff -pur l1/fs/proc/base.c l2/fs/proc/base.c
--- l1/fs/proc/base.c   2005-04-07 23:18:47.0 +0200
+++ l2/fs/proc/base.c   2005-04-10 14:00:28.0 +0200
@@ -35,8 +35,18 @@
 #include linux/seccomp.h
 #include linux/cpuset.h
 #include linux/audit.h
+#include linux/module.h
+#include linux/moduleparam.h
 #include internal.h
 
+static int proc_privacy;
+module_param_named(privacy, proc_privacy, uint, 0);
+MODULE_PARM_DESC(umask, restrict permissions of files in /proc/pid);
+
+static gid_t proc_gid;
+module_param_named(gid, proc_gid, uint, 0);
+MODULE_PARM_DESC(gid, process admin group);
+
 /*
  * For hysterical

[PATCH 11/17] doc: ReSTify Yama.txt

2017-05-13 Thread Kees Cook
Adjusts for ReST markup and moves under LSM admin guide.

Signed-off-by: Kees Cook <keesc...@chromium.org>
---
 .../Yama.txt => admin-guide/LSM/Yama.rst}  | 55 --
 Documentation/admin-guide/LSM/index.rst|  1 +
 Documentation/security/00-INDEX|  2 -
 MAINTAINERS|  1 +
 security/yama/Kconfig  |  3 +-
 5 files changed, 33 insertions(+), 29 deletions(-)
 rename Documentation/{security/Yama.txt => admin-guide/LSM/Yama.rst} (60%)

diff --git a/Documentation/security/Yama.txt 
b/Documentation/admin-guide/LSM/Yama.rst
similarity index 60%
rename from Documentation/security/Yama.txt
rename to Documentation/admin-guide/LSM/Yama.rst
index d9ee7d7a6c7f..13468ea696b7 100644
--- a/Documentation/security/Yama.txt
+++ b/Documentation/admin-guide/LSM/Yama.rst
@@ -1,13 +1,14 @@
+
+Yama
+
+
 Yama is a Linux Security Module that collects system-wide DAC security
 protections that are not handled by the core kernel itself. This is
-selectable at build-time with CONFIG_SECURITY_YAMA, and can be controlled
-at run-time through sysctls in /proc/sys/kernel/yama:
-
-- ptrace_scope
+selectable at build-time with ``CONFIG_SECURITY_YAMA``, and can be controlled
+at run-time through sysctls in ``/proc/sys/kernel/yama``:
 
-==
-
-ptrace_scope:
+ptrace_scope
+
 
 As Linux grows in popularity, it will become a larger target for
 malware. One particularly troubling weakness of the Linux process
@@ -25,47 +26,49 @@ exist and remain possible if ptrace is allowed to operate 
as before.
 Since ptrace is not commonly used by non-developers and non-admins, system
 builders should be allowed the option to disable this debugging system.
 
-For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
+For a solution, some applications use ``prctl(PR_SET_DUMPABLE, ...)`` to
 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
 do not. A more general solution is to only allow ptrace directly from a
 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
-work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
+work), or with ``CAP_SYS_PTRACE`` (i.e. "gdb --pid=PID", and "strace -p PID"
 still work as root).
 
 In mode 1, software that has defined application-specific relationships
 between a debugging process and its inferior (crash handlers, etc),
-prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
-other process (and its descendants) are allowed to call PTRACE_ATTACH
+``prctl(PR_SET_PTRACER, pid, ...)`` can be used. An inferior can declare which
+other process (and its descendants) are allowed to call ``PTRACE_ATTACH``
 against it. Only one such declared debugging process can exists for
 each inferior at a time. For example, this is used by KDE, Chromium, and
 Firefox's crash handlers, and by Wine for allowing only Wine processes
 to ptrace each other. If a process wishes to entirely disable these ptrace
-restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
+restrictions, it can call ``prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)``
 so that any otherwise allowed process (even those in external pid namespaces)
 may attach.
 
-The sysctl settings (writable only with CAP_SYS_PTRACE) are:
+The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are:
 
-0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
+0 - classic ptrace permissions:
+a process can ``PTRACE_ATTACH`` to any other
 process running under the same uid, as long as it is dumpable (i.e.
 did not transition uids, start privileged, or have called
-prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
+``prctl(PR_SET_DUMPABLE...)`` already). Similarly, ``PTRACE_TRACEME`` is
 unchanged.
 
-1 - restricted ptrace: a process must have a predefined relationship
-with the inferior it wants to call PTRACE_ATTACH on. By default,
+1 - restricted ptrace:
+a process must have a predefined relationship
+with the inferior it wants to call ``PTRACE_ATTACH`` on. By default,
 this relationship is that of only its descendants when the above
 classic criteria is also met. To change the relationship, an
-inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
-an allowed debugger PID to call PTRACE_ATTACH on the inferior.
-Using PTRACE_TRACEME is unchanged.
+inferior can call ``prctl(PR_SET_PTRACER, debugger, ...)`` to declare
+an allowed debugger PID to call ``PTRACE_ATTACH`` on the inferior.
+Using ``PTRACE_TRACEME`` is unchanged.
 
-2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
-with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
+2 - admin-only attach:
+only pr

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

2015-10-15 Thread Paul Turner
ural than the file-system.  It also does
>> >
>> > How are they even comparable?  Sure ioctl inputs are variable-formed
>> > and its definitions aren't closely scrutinized but other than those
>> > it's a programmable system-call interface and how programs use and
>> > interact with them is completely different from how a program
>> > interacts with cgroupfs.
>>
>> They're exactly comparable in that every cgroup. api now
>> needs some magic equivalent $KEY defined.  I don't understand how
>> you're proposing these would be generated or managed.
>
> Not everything.  Just the ones which make sense in-process.  This is
> exactly the process we need to go through when introducing new
> syscalls.  Why is this a surprise?  We want to scrutinize them, hard.

I'm talking only about the control->$KEY mapping.  Yes it would be a
subset, but this seems a large step back in usability.

>
>> > It doesn't have to parse out the path,
>> > compose the knob path, open and format the data into it
>>
>> There's nothing hard about this.  Further, we already have to do
>> exactly this at the process level; which means abstractions for this
>
> I'm not following.  Why would it need to do that already?

Because the process-level interface will continue to work the way it
does today.  That means we still need to implement these operations.

This same library code could be shared for applications to use on
their private, sub-process, controls.

>
>> already exist; removing this property does not change their presence
>> of requirement, but instead means they must be duplicated for the
>> in-thread case.
>>
>> Even ignoring that the libraries for this can be shared between thread
>> and process, this is also generally easier to work with than magic
>> $KEY values.
>
> This is like saying syscalls are worse in terms of progammability
> compared to opening and writing formatted strings for setting
> attributes.  If that's what you're saying, let's just agree to disgree
> on this one.

The goal of such a system is as much administration as it is a
programmable interface.  There's a reason much configuration is
specified by sysctls and not syscalls.

>
>> > all the while
>> > not being sure whether the file it's operating on is even the right
>> > one anymore or the sub-hierarchcy it's assuming is still there.
>>
>> One possible resolution to this has been proposed several times:
>>   Have the sub-process hierarchy exposed in an independent and fixed 
>> location.
>>
>> >> not seem to resolve your concerns regarding races; the application
>> >> must still coordinate internally when concurrently calling
>> >> set_resource().
>> >
>> > I have no idea where you're going with this.  When did the internal
>> > synchronization inside a process become an issue?  Sure, if a thread
>> > does *(int *)=0, we can't protect other threads from it.  Also, why
>> > would it be a problem?  If two perform set_resource() on the same
>> > thread, one will be executed after the other.  What are you talking
>> > about?
>>
>> It was my impression that you'd had atomicity concerns regarding
>> file-system operations such as writes for updates previously.  If you
>> have no concerns within a sub-processes operation then this can be
>> discarded.
>
> That's comparing apples and oranges.  Threads being moved around and
> hierarchies changing beneath them present a whole different issues
> than someone else setting an attribute to a different value.  The
> operations might fail, might set properties on the wrong group.
>

There are no differences between using VFS and your proposed API for this.

>> >> 5) How does an external agent coordinate when a resource must be
>> >> removed from a sub-hierarchy?
>> >
>> > That sort of restriction should generally be put at the higher level.
>> > Thread-level resource control should be cooperative with the
>> > application if at all necessary and in those cases just set the limit
>> > on the sub-hierarchy would work.
>> >
>>
>> Could you expand on how you envision this being cooperative?  This
>> seems tricky to me, particularly when limits are involved.
>>
>> How do I even arbitrate which external agents are allowed control?
>
> I think we're talking past each other.  If you wanna put restrictions
> on the process as whole, do it at the higher level.  If you wanna
> fiddle with in-process resource distribution, you just have to assume
> that the application itself is cooperative or at least not malicious.
>

Linux v2.6.21-rc3

2007-03-06 Thread Linus Torvalds
  paravirt: re-enable COMPAT_VDSO

James Simmons (1):
  fbdev: fix kconfig error if FB_DDC=n

Jan Altenberg (1):
  [GIANFAR]: Fix compile error in latest git

Jan Beulich (1):
  adjust legacy IDE resource setting (v2)

Jaroslav Kysela (1):
  [ALSA] version 1.0.14rc3

Jason Gaston (1):
  ahci: RAID mode SATA patch for Intel ICH9M

Jay Vosburgh (3):
  bonding: fix double dev_add_pack
  bonding: only receive ARPs for us
  bonding: Improve IGMP join processing

Jean Delvare (2):
  V4L/DVB (5258): Cafe_ccic: fix compiler warning
  io_apic.h needs apicdef.h

Jeff Dike (8):
  uml: fix host LDT lookup initialization locking, try 2
  uml: add back accidentally removed error
  uml: host VDSO fix
  uml: pte_mkread fix
  linux/audit.h needs linux/types.h
  uml: fix formatting violations in signal delivery code
  uml: add a debugging message
  uml: comment the initialization of a global

Jeff Garzik (5):
  [libata] change master/slave IDENTIFY order
  [libata] pata_{legacy,sc1200,sl82c105}: add missing hooks
  [libata] pata_cmd64x: fix driver description in comments
  [netdrvr] tulip, de2104x: fix typo: s/__sparc_/__sparc__/
  [libata] pata_jmicron: build fix

Jeremy Katz (1):
  KVM: Move virtualization deactivation from CPU_DEAD state to 
CPU_DOWN_PREPARE

Jin-Bong lee (1):
  V4L/DVB (5276): Cxusb: fix firmware patch for big endian systems

Jiri Kosina (6):
  USB HID: use CONFIG_HID_DEBUG for outputting report descriptor
  HID: fix bug in zeroing the last field byte in output reports
  HID: fix possible double-free on error path in hid parser
  HID: fix broken Logitech S510 keyboard report descriptor; make extra keys 
work
  HID: add git tree information to MAINTAINERS
  HID: fix Logitech DiNovo Edge touchwheel and Logic3 /SpectraVideo middle 
button

Joe Sauer (1):
  [ALSA] soc - Fix WM9712 register cache entry

Joerg Roedel (2):
  KVM: vmx: hack set_cr0_no_modeswitch() to actually do modeswitch
  KVM: SVM: intercept SMI to handle it at host level

Johannes Berg (2):
  schedule wext/rtnl for removal
  [NET]: Fix compat_sock_common_getsockopt typo.

John Heffner (1):
  [TCP]: Document several sysctls.

John Stultz (1):
  clocksource init adjustments (fix bug #7426)

Josh Triplett (1):
  Publish rcutorture module parameters via sysfs, read-only

Julien BLACHE (1):
  USB HID: Fix USB vendor and product IDs endianness for USB HID devices

Karsten Keil (1):
  Fix buffer overflow and races in capi debug functions

Kristen Carlson Accardi (1):
  ACPI: make bay depend on dock

Krzysztof Halasa (1):
  [HDLC] Fix dev-header_cache_update having a random value.

Lee Schermerhorn (1):
  [IA64] always build arch/ia64/lib/xor.o

Li Yang (2):
  ucc_geth: Fix BD processing
  ucc_geth: returns NETDEV_TX_BUSY when BD ring is full

Liam Girdwood (1):
  [ALSA] soc - WM9712 PCM volume

Linsys Contractor Mithlesh Thukral (2):
  NetXen: Updates, removal of unsupported features and minor bug fixes.
  NetXen: Fix second rmmod failure observed on PowerPC machines.

Linus Torvalds (2):
  Revert [PATCH] LOG2: Alter get_order() so that it can make use of 
ilog2() on a constant
  Linux 2.6.21-rc3

Maciej W. Rozycki (1):
  dz: remove struct pt_regs references

Magnus Damm (2):
  ide-cs: Update device table
  [IA64] kexec: Use EFI_LOADER_DATA for ELF core header

Marcel Holtmann (1):
  Fix buffer overflow in Omnikey CardMan 4040 driver (CVE-2007-0005)

Marek Vašut (1):
  ARM: OMAP: OMAP310 Serial

Mark Gross (1):
  minor updat to tlclk Kconfig entry

Mark Lord (2):
  sdhci: make isr tolerant of read errors
  Fix 2.6.21 rfcomm lockups

Markus Rechberger (1):
  KVM: Use page_private()/set_page_private() apis

Martin Schwidefsky (1):
  [S390] kprobes breaks BUG_ON

Matthew Percival (1):
  ARM: OMAP: dmtimer.c omap1 register fix

Maxim Levitsky (3):
  dmfe: trivial/spelling fixes
  dmfe: fix two bugs
  dmfe: Fix link detection

Michael Halcrow (4):
  eCryptfs: resolve lower page unlocking problem
  eCryptfs: set O_LARGEFILE when opening lower file
  eCryptfs: remove unnecessary flush_dcache_page()
  eCryptfs: no path_release() after path_lookup() error

Michael Holzheu (1):
  [S390] tape: Compression overwrites crypto setting

Michael Krufky (2):
  V4L/DVB (5295): Digitv: open nxt6000 i2c_gate for TDED4 tuner handling
  V4L/DVB (5260): Cx88-blackbird: allow usage of both 376836 and 262144 
sized firmware images

Michal Miroslaw (5):
  [NETFILTER]: nfnetlink_log: fix reference leak
  [NETFILTER]: nfnetlink_log: fix use after free
  [NETFILTER]: nfnetlink_log: fix NULL pointer dereference
  [NETFILTER]: nfnetlink_log: fix possible NULL pointer dereference
  [NETFILTER]: nfnetlink_log: fix reference counting

Michal Piotrowski (1):
  char/epca.c