From: Greg Kroah-Hartman Date: Thu, 28 Sep 2017 13:34:27 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v3.18.73~40 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=efda118aa24141aca4ac789cfd923dce9490ade0;p=thirdparty%2Fkernel%2Fstable-queue.git 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 index 00000000000..30259d68267 --- /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 +Date: Fri, 8 Sep 2017 18:48:33 +0800 +Subject: cifs: release auth_key.response for reconnect. + +From: Shu Wang + +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 +Signed-off-by: Steve French +Reviewed-by: Ronnie Sahlberg +Signed-off-by: Greg Kroah-Hartman + +--- + 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 index 00000000000..78217727dd5 --- /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 +Date: Thu, 7 Sep 2017 16:03:27 +0800 +Subject: cifs: release cifs root_cred after exit_cifs + +From: Shu Wang + +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 +Signed-off-by: Steve French +Reviewed-by: Ronnie Sahlberg +Signed-off-by: Greg Kroah-Hartman + +--- + 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 index 00000000000..1b014b65c6b --- /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 +Date: Thu, 14 Sep 2017 11:42:17 +0200 +Subject: fs/proc: Report eip/esp in /prod/PID/stat for coredumping + +From: John Ogness + +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 +Signed-off-by: John Ogness +Reviewed-by: Andy Lutomirski +Cc: Tycho Andersen +Cc: Kees Cook +Cc: Peter Zijlstra +Cc: Brian Gerst +Cc: Tetsuo Handa +Cc: Borislav Petkov +Cc: Al Viro +Cc: Linux API +Cc: Andrew Morton +Cc: Linus Torvalds +Link: http://lkml.kernel.org/r/87poatfwg6.fsf@linutronix.de +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include + #include ++#include + #include + #include + #include +@@ -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);