+ fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch added to -mm tree

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

 



The patch titled
     Subject: fs/proc: report eip/esp in /prod/PID/stat for coredumping
has been added to the -mm tree.  Its filename is
     fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: John Ogness <john.ogness@xxxxxxxxxxxxx>
Subject: fs/proc: report eip/esp in /prod/PID/stat for coredumping

0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat")
stopped reporting eip/esp because it is racy and dangerous for executing
tasks.  The comment adds:

    As far as I know, there are no use programs that make any
    material use of these fields, so just get rid of them.

However, existing userspace core-dump-handler applications (for example,
minicoredumper) are using these fields since they provide an excellent
cross-platform interface to these valuable pointers.  So that commit
introduced a user space visible regression.

Partially revert the change and make the readout possible for tasks with
the proper permissions and only if the target task has the PF_DUMPCORE
flag set.

Link: http://lkml.kernel.org/r/87poatfwg6.fsf@xxxxxxxxxxxxx
Fixes: 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in> /proc/PID/stat")
Signed-off-by: John Ogness <john.ogness@xxxxxxxxxxxxx>
Reported-by: Marco Felsch <marco.felsch@xxxxxxx>
Reviewed-by: Andy Lutomirski <luto@xxxxxxxxxx>
Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Kees Cook <keescook@xxxxxxxxxxxx>
Cc: Tycho Andersen <tycho.andersen@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 fs/proc/array.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff -puN fs/proc/array.c~fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping fs/proc/array.c
--- a/fs/proc/array.c~fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping
+++ a/fs/proc/array.c
@@ -421,7 +421,15 @@ static int do_task_stat(struct seq_file
 		 * esp and eip are intentionally zeroed out.  There is no
 		 * non-racy way to read them without freezing the task.
 		 * Programs that need reliable values can use ptrace(2).
+		 *
+		 * The only exception is if the task is core dumping because
+		 * a program is not able to use ptrace(2) in that case. It is
+		 * safe because the task has stopped executing permanently.
 		 */
+		if (permitted && (task->flags & PF_DUMPCORE)) {
+			eip = KSTK_EIP(task);
+			esp = KSTK_ESP(task);
+		}
 	}
 
 	get_task_comm(tcomm, task);
_

Patches currently in -mm which might be from john.ogness@xxxxxxxxxxxxx are

fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]