1. 13 2月, 2007 2 次提交
  2. 12 2月, 2007 1 次提交
  3. 02 2月, 2007 1 次提交
  4. 27 1月, 2007 1 次提交
    • A
      [PATCH] Fix NULL ->nsproxy dereference in /proc/*/mounts · 863c4702
      Alexey Dobriyan 提交于
      /proc/*/mounstats was fixed, all right, but...
      
      To reproduce:
      
      	while true; do
      		find /proc -type f 2>/dev/null | xargs cat 1>/dev/null 2>/dev/null;
      	done
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address 0000000c
       printing eip:
      c01754df
      *pde = 00000000
      Oops: 0000 [#28]
      Modules linked in: af_packet ohci_hcd e1000 ehci_hcd uhci_hcd usbcore xfs
      CPU:    0
      EIP:    0060:[<c01754df>]    Not tainted VLI
      EFLAGS: 00010286   (2.6.20-rc5 #1)
      EIP is at mounts_open+0x1c/0xac
      eax: 00000000   ebx: d5898ac0   ecx: d1d27b18   edx: d1d27a50
      esi: e6083e10   edi: d3c87f38   ebp: d5898ac0   esp: d3c87ef0
      ds: 007b   es: 007b   ss: 0068
      Process cat (pid: 18071, ti=d3c86000 task=f7d5f070 task.ti=d3c86000)
      Stack: d5898ac0 e6083e10 d3c87f38 c01754c3 c0147c91 c18c52c0 d343f314 d5898ac0
             00008000 d3c87f38 ffffff9c c0147e09 d5898ac0 00000000 00000000 c0147e4b
             00000000 d3c87f38 d343f314 c18c52c0 c015e53e 00001000 08051000 00000101
      Call Trace:
       [<c01754c3>] mounts_open+0x0/0xac
       [<c0147c91>] __dentry_open+0xa1/0x18c
       [<c0147e09>] nameidata_to_filp+0x31/0x3a
       [<c0147e4b>] do_filp_open+0x39/0x40
       [<c015e53e>] seq_read+0x128/0x2aa
       [<c0147e8c>] do_sys_open+0x3a/0x6d
       [<c0147efa>] sys_open+0x1c/0x20
       [<c0102b76>] sysenter_past_esp+0x5f/0x85
       [<c02a0033>] unix_stream_recvmsg+0x3bf/0x4bf
       =======================
      Code: 5d c3 89 d8 e8 06 e0 f9 ff eb bd 0f 0b eb fe 55 57 56 53 89 d5 8b 40 f0 31 d2 e8 02 c1 fa ff 89 c2 85 c0 74 5c 8b 80 48 04 00 00 <8b> 58 0c 85 db 74 02 ff 03 ff 4a 08 0f 94 c0 84 c0 75 74 85 db
      EIP: [<c01754df>] mounts_open+0x1c/0xac SS:ESP 0068:d3c87ef0
      
      A race with do_exit()'s call to exit_namespaces().
      Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      863c4702
  5. 11 12月, 2006 1 次提交
    • A
      [PATCH] io-accounting: report in procfs · aba76fdb
      Andrew Morton 提交于
      Add a simple /proc/pid/io to show the IO accounting fields.
      
      Maybe this shouldn't be merged in mainline - the preferred reporting channel
      is taskstats.  But given the poor state of our userspace support for
      taskstats, this is useful for developer-testing, at least.  And it improves
      the changes that the procps developers will wire it up into top(1).  Opinions
      are sought.
      
      The patch also wires up the existing IO-accounting fields.
      
      It's a bit racy on 32-bit machines: if process A reads process B's
      /proc/pid/io while process B is updating one of those 64-bit counters, process
      A could see an intermediate result.
      
      Cc: Jay Lan <jlan@sgi.com>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Chris Sturtivant <csturtiv@sgi.com>
      Cc: Tony Ernst <tee@sgi.com>
      Cc: Guillaume Thouvenin <guillaume.thouvenin@bull.net>
      Cc: David Wright <daw@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aba76fdb
  6. 09 12月, 2006 3 次提交
  7. 08 12月, 2006 2 次提交
  8. 26 11月, 2006 1 次提交
    • V
      [PATCH] mounstats NULL pointer dereference · 701e054e
      Vasily Tarasov 提交于
      OpenVZ developers team has encountered the following problem in 2.6.19-rc6
      kernel. After some seconds of running script
      
      while [[ 1 ]]
      do
      	find  /proc -name mountstats | xargs cat
      done
      
      this Oops appears:
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address
      00000010
       printing eip:
      c01a6b70
      *pde = 00000000
      Oops: 0000 [#1]
      SMP
      Modules linked in: xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle
      iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables
      parport_pc lp parport sunrpc af_packet thermal processor fan button battery
      asus_acpi ac ohci_hcd ehci_hcd usbcore i2c_nforce2 i2c_core tg3 floppy
      pata_amd
      ide_cd cdrom sata_nv libata
      CPU:    1
      EIP:    0060:[<c01a6b70>]    Not tainted VLI
      EFLAGS: 00010246   (2.6.19-rc6 #2)
      EIP is at mountstats_open+0x70/0xf0
      eax: 00000000   ebx: e6247030   ecx: e62470f8   edx: 00000000
      esi: 00000000   edi: c01a6b00   ebp: c33b83c0   esp: f4105eb4
      ds: 007b   es: 007b   ss: 0068
      Process cat (pid: 6044, ti=f4105000 task=f4104a70 task.ti=f4105000)
      Stack: c33b83c0 c04ee940 f46a4a80 c33b83c0 e4df31b4 c01a6b00 f4105000 c0169231
             e4df31b4 c33b83c0 c33b83c0 f4105f20 00000003 f4105000 c0169445 f2503cf0
             f7f8c4c0 00008000 c33b83c0 00000000 00008000 c0169350 f4105f20 00008000
      Call Trace:
       [<c01a6b00>] mountstats_open+0x0/0xf0
       [<c0169231>] __dentry_open+0x181/0x250
       [<c0169445>] nameidata_to_filp+0x35/0x50
       [<c0169350>] do_filp_open+0x50/0x60
       [<c01873d6>] seq_read+0xc6/0x300
       [<c0169511>] get_unused_fd+0x31/0xc0
       [<c01696d3>] do_sys_open+0x63/0x110
       [<c01697a7>] sys_open+0x27/0x30
       [<c01030bd>] sysenter_past_esp+0x56/0x79
       =======================
      Code: 45 74 8b 54 24 20 89 44 24 08 8b 42 f0 31 d2 e8 47 cb f8 ff 85 c0 89 c3
      74 51 8d 80 a0 04 00 00 e8 46 06 2c 00 8b 83 48 04 00 00 <8b> 78 10 85 ff 74
      03
      f0 ff 07 b0 01 86 83 a0 04 00 00 f0 ff 4b
      EIP: [<c01a6b70>] mountstats_open+0x70/0xf0 SS:ESP 0068:f4105eb4
      
      The problem is that task->nsproxy can be equal NULL for some time during
      task exit. This patch fixes the BUG.
      Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      701e054e
  9. 21 10月, 2006 1 次提交
  10. 17 10月, 2006 1 次提交
  11. 02 10月, 2006 14 次提交
  12. 30 9月, 2006 1 次提交
  13. 16 7月, 2006 1 次提交
  14. 15 7月, 2006 2 次提交
  15. 01 7月, 2006 1 次提交
  16. 27 6月, 2006 7 次提交
    • E
      [PATCH] SELinux: Add sockcreate node to procattr API · 42c3e03e
      Eric Paris 提交于
      Below is a patch to add a new /proc/self/attr/sockcreate A process may write a
      context into this interface and all subsequent sockets created will be labeled
      with that context.  This is the same idea as the fscreate interface where a
      process can specify the label of a file about to be created.  At this time one
      envisioned user of this will be xinetd.  It will be able to better label
      sockets for the actual services.  At this time all sockets take the label of
      the creating process, so all xinitd sockets would just be labeled the same.
      
      I tested this by creating a tcp sender and listener.  The sender was able to
      write to this new proc file and then create sockets with the specified label.
      I am able to be sure the new label was used since the avc denial messages
      kicked out by the kernel included both the new security permission
      setsockcreate and all the socket denials were for the new label, not the label
      of the running process.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      42c3e03e
    • O
      [PATCH] cleanup next_tid() · c1df7fb8
      Oleg Nesterov 提交于
      Try to make next_tid() a bit more readable and deletes unnecessary
      "pid_alive(pos)" check.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c1df7fb8
    • O
      [PATCH] simplify/fix first_tid() · a872ff0c
      Oleg Nesterov 提交于
      first_tid:
      
      	/* If nr exceeds the number of threads there is nothing todo */
      	if (nr) {
      		if (nr >= get_nr_threads(leader))
      			goto done;
      	}
      
      This is not reliable: sub-threads can exit after this check, so the
      'for' loop below can overlap and proc_task_readdir() can return an
      already filldir'ed dirents.
      
      	for (; pos && pid_alive(pos); pos = next_thread(pos)) {
      		if (--nr > 0)
      			continue;
      
      Off-by-one error, will return 'leader' when nr == 1.
      
      This patch tries to fix these problems and simplify the code.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a872ff0c
    • E
      [PATCH] proc: Remove tasklist_lock from proc_task_readdir. · cc288738
      Eric W. Biederman 提交于
      This is just like my previous removal of tasklist_lock from first_tgid, and
      next_tgid.  It simply had to wait until it was rcu safe to walk the thread
      list.
      
      This should be the last instance of the tasklist_lock in proc.  So user
      processes should not be able to influence the tasklist lock hold times.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc288738
    • E
      [PATCH] proc: Cleanup proc_fd_access_allowed · df26c40e
      Eric W. Biederman 提交于
      In process of getting proc_fd_access_allowed to work it has developed a few
      warts.  In particular the special case that always allows introspection and
      the special case to allow inspection of kernel threads.
      
      The special case for introspection is needed for /proc/self/mem.
      
      The special case for kernel threads really should be overridable
      by security modules.
      
      So consolidate these checks into ptrace.c:may_attach().
      
      The check to always allow introspection is trivial.
      
      The check to allow access to kernel threads, and zombies is a little
      trickier.  mem_read and mem_write already verify an mm exists so it isn't
      needed twice.  proc_fd_access_allowed only doesn't want a check to verify
      task->mm exits, s it prevents all access to kernel threads.  So just move
      the task->mm check into ptrace_attach where it is needed for practical
      reasons.
      
      I did a quick audit and none of the security modules in the kernel seem to
      care if they are passed a task without an mm into security_ptrace.  So the
      above move should be safe and it allows security modules to come up with
      more restrictive policy.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      df26c40e
    • E
      [PATCH] proc: Use sane permission checks on the /proc/<pid>/fd/ symlinks · 778c1144
      Eric W. Biederman 提交于
      Since 2.2 we have been doing a chroot check to see if it is appropriate to
      return a read or follow one of these magic symlinks.  The chroot check was
      asking a question about the visibility of files to the calling process and
      it was actually checking the destination process, and not the files
      themselves.  That test was clearly bogus.
      
      In my first pass through I simply fixed the test to check the visibility of
      the files themselves.  That naive approach to fixing the permissions was
      too strict and resulted in cases where a task could not even see all of
      it's file descriptors.
      
      What has disturbed me about relaxing this check is that file descriptors
      are per-process private things, and they are occasionaly used a user space
      capability tokens.  Looking a little farther into the symlink path on /proc
      I did find userid checks and a check for capability (CAP_DAC_OVERRIDE) so
      there were permissions checking this.
      
      But I was still concerned about privacy.  Besides /proc there is only one
      other way to find out this kind of information, and that is ptrace.  ptrace
      has been around for a long time and it has a well established security
      model.
      
      So after thinking about it I finally realized that the permission checks
      that make sense are the permission checks applied to ptrace_attach.  The
      checks are simple per process, and won't cause nasty surprises for people
      coming from less capable unices.
      
      Unfortunately there is one case that the current ptrace_attach test does
      not cover: Zombies and kernel threads.  Single stepping those kinds of
      processes is impossible.  Being able to see which file descriptors are open
      on these tasks is important to lsof, fuser and friends.  So for these
      special processes I made the rule you can't find out unless you have
      CAP_SYS_PTRACE.
      
      These proc permission checks should now conform to the principle of least
      surprise.  As well as using much less code to implement :)
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      778c1144
    • E
      [PATCH] proc: optimize proc_check_dentry_visible · 5b0c1dd3
      Eric W. Biederman 提交于
      The code doesn't need to sleep to when making this check so I can just do the
      comparison and not worry about the reference counts.
      
      TODO: While looking at this I realized that my original cleanup did not push
      the permission check far enough down into the stack.  The call of
      proc_check_dentry_visible needs to move out of the generic proc
      readlink/follow link code and into the individual get_link instances.
      Otherwise the shared resources checks are not quite correct (shared
      files_struct does not require a shared fs_struct), and there are races with
      unshare.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5b0c1dd3