4.9-stable patches

added patches:
	cifs-release-auth_key.response-for-reconnect.patch
	cifs-release-cifs-root_cred-after-exit_cifs.patch
	fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch

diff --git a/queue-4.9/cifs-release-auth_key.response-for-reconnect.patch b/queue-4.9/cifs-release-auth_key.response-for-reconnect.patch
new file mode 100644 (file)
index 0000000..30259d6
--- /dev/null
+++ b/queue-4.9/cifs-release-auth_key.response-for-reconnect.patch
@@ -0,0 +1,58 @@
+From f5c4ba816315d3b813af16f5571f86c8d4e897bd Mon Sep 17 00:00:00 2001
+From: Shu Wang <shuwang@redhat.com>
+Date: Fri, 8 Sep 2017 18:48:33 +0800
+Subject: cifs: release auth_key.response for reconnect.
+
+From: Shu Wang <shuwang@redhat.com>
+
+commit f5c4ba816315d3b813af16f5571f86c8d4e897bd upstream.
+
+There is a race that cause cifs reconnect in cifs_mount,
+- cifs_mount
+  - cifs_get_tcp_session
+    - [ start thread cifs_demultiplex_thread
+      - cifs_read_from_socket: -ECONNABORTED
+        - DELAY_WORK smb2_reconnect_server ]
+  - cifs_setup_session
+  - [ smb2_reconnect_server ]
+
+auth_key.response was allocated in cifs_setup_session, and
+will release when the session destoried. So when session re-
+connect, auth_key.response should be check and released.
+
+Tested with my system:
+CIFS VFS: Free previous auth_key.response = ffff8800320bbf80
+
+A simple auth_key.response allocation call trace:
+- cifs_setup_session
+- SMB2_sess_setup
+- SMB2_sess_auth_rawntlmssp_authenticate
+- build_ntlmssp_auth_blob
+- setup_ntlmv2_rsp
+
+Signed-off-by: Shu Wang <shuwang@redhat.com>
+Signed-off-by: Steve French <smfrench@gmail.com>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/connect.c |    8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -4071,6 +4071,14 @@ cifs_setup_session(const unsigned int xi
+       cifs_dbg(FYI, "Security Mode: 0x%x Capabilities: 0x%x TimeAdjust: %d\n",
+                server->sec_mode, server->capabilities, server->timeAdj);
+ 
++      if (ses->auth_key.response) {
++              cifs_dbg(VFS, "Free previous auth_key.response = %p\n",
++                       ses->auth_key.response);
++              kfree(ses->auth_key.response);
++              ses->auth_key.response = NULL;
++              ses->auth_key.len = 0;
++      }
++
+       if (server->ops->sess_setup)
+               rc = server->ops->sess_setup(xid, ses, nls_info);
+ 

diff --git a/queue-4.9/cifs-release-cifs-root_cred-after-exit_cifs.patch b/queue-4.9/cifs-release-cifs-root_cred-after-exit_cifs.patch
new file mode 100644 (file)
index 0000000..7821772
--- /dev/null
+++ b/queue-4.9/cifs-release-cifs-root_cred-after-exit_cifs.patch
@@ -0,0 +1,47 @@
+From 94183331e815617246b1baa97e0916f358c794bb Mon Sep 17 00:00:00 2001
+From: Shu Wang <shuwang@redhat.com>
+Date: Thu, 7 Sep 2017 16:03:27 +0800
+Subject: cifs: release cifs root_cred after exit_cifs
+
+From: Shu Wang <shuwang@redhat.com>
+
+commit 94183331e815617246b1baa97e0916f358c794bb upstream.
+
+memory leak was found by kmemleak. exit_cifs_spnego
+should be called before cifs module removed, or
+cifs root_cred will not be released.
+
+kmemleak report:
+unreferenced object 0xffff880070a3ce40 (size 192):
+  backtrace:
+     kmemleak_alloc+0x4a/0xa0
+     kmem_cache_alloc+0xc7/0x1d0
+     prepare_kernel_cred+0x20/0x120
+     init_cifs_spnego+0x2d/0x170 [cifs]
+     0xffffffffc07801f3
+     do_one_initcall+0x51/0x1b0
+     do_init_module+0x60/0x1fd
+     load_module+0x161e/0x1b60
+     SYSC_finit_module+0xa9/0x100
+     SyS_finit_module+0xe/0x10
+
+Signed-off-by: Shu Wang <shuwang@redhat.com>
+Signed-off-by: Steve French <smfrench@gmail.com>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/cifsfs.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -1360,7 +1360,7 @@ exit_cifs(void)
+       exit_cifs_idmap();
+ #endif
+ #ifdef CONFIG_CIFS_UPCALL
+-      unregister_key_type(&cifs_spnego_key_type);
++      exit_cifs_spnego();
+ #endif
+       cifs_destroy_request_bufs();
+       cifs_destroy_mids();

diff --git a/queue-4.9/fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch b/queue-4.9/fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch
new file mode 100644 (file)
index 0000000..1b014b6
--- /dev/null
+++ b/queue-4.9/fs-proc-report-eip-esp-in-prod-pid-stat-for-coredumping.patch
@@ -0,0 +1,74 @@
+From fd7d56270b526ca3ed0c224362e3c64a0f86687a Mon Sep 17 00:00:00 2001
+From: John Ogness <john.ogness@linutronix.de>
+Date: Thu, 14 Sep 2017 11:42:17 +0200
+Subject: fs/proc: Report eip/esp in /prod/PID/stat for coredumping
+
+From: John Ogness <john.ogness@linutronix.de>
+
+commit fd7d56270b526ca3ed0c224362e3c64a0f86687a upstream.
+
+Commit 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.
+
+Fixes: 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in> /proc/PID/stat")
+Reported-by: Marco Felsch <marco.felsch@preh.de>
+Signed-off-by: John Ogness <john.ogness@linutronix.de>
+Reviewed-by: Andy Lutomirski <luto@kernel.org>
+Cc: Tycho Andersen <tycho.andersen@canonical.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Linux API <linux-api@vger.kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: http://lkml.kernel.org/r/87poatfwg6.fsf@linutronix.de
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/proc/array.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/proc/array.c
++++ b/fs/proc/array.c
+@@ -60,6 +60,7 @@
+ #include <linux/tty.h>
+ #include <linux/string.h>
+ #include <linux/mman.h>
++#include <linux/sched.h>
+ #include <linux/proc_fs.h>
+ #include <linux/ioport.h>
+ #include <linux/uaccess.h>
+@@ -416,7 +417,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);