From: Kingsley Cheung <kingsley@aurema.com>

Is is possible to examine the data of tasks currently existing in the system
which are not threads of the same thread group.

For example, the only task in the group where init is group leader is itself:

gen2 02:50:44 ~: ls /proc/1/task
1

However, I can then read the contents of 'stat' for any other task in the
system:

gen2 02:49:45 ~: cat /proc/1/task/$$/stat
1669 (bash) S 1668 1669 1669 34816 1730 256 1480 6479 12 4 8 5 5 17 15 0 1 0
+8065 3252224 451 4294967295 134512640 134955932 3221225104 3221222840
+4294960144 0 65536 3686404 1266761467 3222442959 0 0 17 0 0 0

I had a look at fs/proc/base.c and found that the 'lookup' functions for
these directories were checking that the task in question existed, but
overlooked the following:

1.  In the function proc_pid_lookup, a check is required to ensure that
    the task in question is a thread group leader.  Without the check, any
    task can have its data retrieved accordingly.  Consider the following.
    There is a multithreaded process 1777.

gen2 23:22:47 /proc/1777: ls task
1777  1778  1779  1780  1781  1782  1783  1784  1785  1786  1787  1788

However, I can read the stat file for its thread 1778 as follows:

gen2 23:22:50 /proc/1777: cat /proc/1778/stat
1778 (multithreadtest) T 1777 1777 1672 34816 1672 64 0 0 0 0 14 17 0 0 15 0 12 0 8871 24727552 104 4294967295 134512640 134515104 3221222496 1077365276 4294960144 0 0 0 0 3222479248 0 0 -1 1 0 0

But 1778 is not meant to show up in /proc/, as intended right?:

gen2 23:22:56 /proc/1777: ls /proc/
1     1365  1661  1793  881        dma          kcore       scsi
10    1371  1662  18    9          driver       kmsg        self
1014  1372  1663  2     909        execdomains  loadavg     slabinfo
1032  14    1664  3     963        fb           locks       stat
1062  15    1665  4     966        filesystems  mdstat      swaps
1066  16    1666  5     buddyinfo  fs           meminfo     sys
1067  1605  1669  6     bus        ide          misc        sysrq-trigger
1087  1610  1670  7     cmdline    interrupts   modules     sysvipc
1095  1611  1671  736   cpuinfo    iomem        mounts      tty
11    1641  1672  8     crypto     ioports      mtrr        uptime
12    1658  17    807   devices    irq          net         version
13    1660  1777  810   diskstats  kallsyms     partitions  vmstat

2.  The other part of the bug is in the function proc_task_lookup.  Here
    there needs to be a check that the task X is indeed a thread of the
    thread group Y when we read /proc/<Y>/task/<X>.

Right now, this check does not exist, which allows for any existing
task to have its data read from another thread group directory.  The
following reads the stat directory of my bash shell from the thread
group 1.

gen2 23:28:07 ~: cd /proc/1
gen2 23:28:10 /proc/1: ls
auxv     cwd      exe  maps  mounts  stat   status  wchan
cmdline  environ  fd   mem   root    statm  task
gen2 23:28:11 /proc/1: ls task
1
gen2 23:28:27 /proc/1: cat task/$$/stat
1671 (bash) S 1670 1671 1671 34817 1802 256 1953 8101 12 4 10 6 9 26 15 0 1 0 5789 3252224 454 4294967295 134512640 134955932 3221225104 3221222840 4294960144 0 65536 3686404 1266761467 3222442959 0 0 17 0 0 0