--- /dev/null
+From f612acfae86af7ecad754ae6a46019be9da05b8e Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Tue, 19 Feb 2019 10:10:38 +0800
+Subject: exec: Fix mem leak in kernel_read_file
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit f612acfae86af7ecad754ae6a46019be9da05b8e upstream.
+
+syzkaller report this:
+BUG: memory leak
+unreferenced object 0xffffc9000488d000 (size 9195520):
+ comm "syz-executor.0", pid 2752, jiffies 4294787496 (age 18.757s)
+ hex dump (first 32 bytes):
+ ff ff ff ff ff ff ff ff a8 00 00 00 01 00 00 00 ................
+ 02 00 00 00 00 00 00 00 80 a1 7a c1 ff ff ff ff ..........z.....
+ backtrace:
+ [<000000000863775c>] __vmalloc_node mm/vmalloc.c:1795 [inline]
+ [<000000000863775c>] __vmalloc_node_flags mm/vmalloc.c:1809 [inline]
+ [<000000000863775c>] vmalloc+0x8c/0xb0 mm/vmalloc.c:1831
+ [<000000003f668111>] kernel_read_file+0x58f/0x7d0 fs/exec.c:924
+ [<000000002385813f>] kernel_read_file_from_fd+0x49/0x80 fs/exec.c:993
+ [<0000000011953ff1>] __do_sys_finit_module+0x13b/0x2a0 kernel/module.c:3895
+ [<000000006f58491f>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
+ [<00000000ee78baf4>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ [<00000000241f889b>] 0xffffffffffffffff
+
+It should goto 'out_free' lable to free allocated buf while kernel_read
+fails.
+
+Fixes: 39d637af5aa7 ("vfs: forbid write access when reading a file into memory")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Thibaut Sautereau <thibaut@sautereau.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exec.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -925,7 +925,7 @@ int kernel_read_file(struct file *file,
+ bytes = kernel_read(file, *buf + pos, i_size - pos, &pos);
+ if (bytes < 0) {
+ ret = bytes;
+- goto out;
++ goto out_free;
+ }
+
+ if (bytes == 0)
--- /dev/null
+From 4a067cf823d9d8e50d41cfb618011c0d4a969c72 Mon Sep 17 00:00:00 2001
+From: Martin Wilck <mwilck@suse.com>
+Date: Thu, 14 Feb 2019 22:57:41 +0100
+Subject: scsi: core: reset host byte in DID_NEXUS_FAILURE case
+
+From: Martin Wilck <mwilck@suse.com>
+
+commit 4a067cf823d9d8e50d41cfb618011c0d4a969c72 upstream.
+
+Up to 4.12, __scsi_error_from_host_byte() would reset the host byte to
+DID_OK for various cases including DID_NEXUS_FAILURE. Commit
+2a842acab109 ("block: introduce new block status code type") replaced this
+function with scsi_result_to_blk_status() and removed the host-byte
+resetting code for the DID_NEXUS_FAILURE case. As the line
+set_host_byte(cmd, DID_OK) was preserved for the other cases, I suppose
+this was an editing mistake.
+
+The fact that the host byte remains set after 4.13 is causing problems with
+the sg_persist tool, which now returns success rather then exit status 24
+when a RESERVATION CONFLICT error is encountered.
+
+Fixes: 2a842acab109 "block: introduce new block status code type"
+Signed-off-by: Martin Wilck <mwilck@suse.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_lib.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/scsi/scsi_lib.c
++++ b/drivers/scsi/scsi_lib.c
+@@ -734,6 +734,7 @@ static blk_status_t __scsi_error_from_ho
+ set_host_byte(cmd, DID_OK);
+ return BLK_STS_TARGET;
+ case DID_NEXUS_FAILURE:
++ set_host_byte(cmd, DID_OK);
+ return BLK_STS_NEXUS;
+ case DID_ALLOC_FAILURE:
+ set_host_byte(cmd, DID_OK);
hugetlbfs-fix-races-and-page-leaks-during-migration.patch
xtensa-fix-get_wchan.patch
bluetooth-fix-locking-in-bt_accept_enqueue-for-bh-context.patch
+exec-fix-mem-leak-in-kernel_read_file.patch
+scsi-core-reset-host-byte-in-did_nexus_failure-case.patch