This is a note to let you know that I've just added the patch titled
ARM: dts: aspeed-evb: Add unit name to memory node
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:03:40 CET 2018
From: Joel Stanley <joel(a)jms.id.au>
Date: Mon, 18 Dec 2017 23:27:03 +1030
Subject: ARM: dts: aspeed-evb: Add unit name to memory node
From: Joel Stanley <joel(a)jms.id.au>
[ Upstream commit e40ed274489a5f516da120186578eb379b452ac6 ]
Fixes a warning when building with W=1.
All of the ASPEED device trees build without warnings now.
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
@@ -16,7 +16,7 @@
bootargs = "console=ttyS4,115200 earlyprintk";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x20000000>;
};
};
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.15/arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -718,16 +718,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.9/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
The fix for brightness setting when setting delay_off=0 introduces
a regression and has truncated commit message. Revert that patch
and apply the one-line change required to fix the original issue
in the way appropriate for the 4.9 code base.
Changes from v1:
- added Reported-by and Signed-off-by tags
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2):
Revert "led: core: Fix brightness setting when setting delay_off=0"
led: core: Clear LED_BLINK_SW flag in led_blink_set()
drivers/leds/led-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.1.4
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -703,16 +703,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.4/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -709,16 +709,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.15/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -709,16 +709,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.14/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 0911287ce32b14fbc8aab0083151d9b54254091c Mon Sep 17 00:00:00 2001
From: Alexei Starovoitov <ast(a)kernel.org>
Date: Fri, 2 Feb 2018 15:14:05 -0800
Subject: [PATCH] bpf: fix bpf_prog_array_copy_to_user() issues
1. move copy_to_user out of rcu section to fix the following issue:
./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
stack backtrace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592
rcu_preempt_sleep_check include/linux/rcupdate.h:301 [inline]
___might_sleep+0x385/0x470 kernel/sched/core.c:6079
__might_sleep+0x95/0x190 kernel/sched/core.c:6067
__might_fault+0xab/0x1d0 mm/memory.c:4532
_copy_to_user+0x2c/0xc0 lib/usercopy.c:25
copy_to_user include/linux/uaccess.h:155 [inline]
bpf_prog_array_copy_to_user+0x217/0x4d0 kernel/bpf/core.c:1587
bpf_prog_array_copy_info+0x17b/0x1c0 kernel/bpf/core.c:1685
perf_event_query_prog_array+0x196/0x280 kernel/trace/bpf_trace.c:877
_perf_ioctl kernel/events/core.c:4737 [inline]
perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4757
2. move *prog under rcu, since it's not ok to dereference it afterwards
3. in a rare case of prog array being swapped between bpf_prog_array_length()
and bpf_prog_array_copy_to_user() calls make sure to copy zeros to user space,
so the user doesn't walk over uninited prog_ids while kernel reported
uattr->query.prog_cnt > 0
Reported-by: syzbot+7dbcd2d3b85f9b608b23(a)syzkaller.appspotmail.com
Fixes: 468e2f64d220 ("bpf: introduce BPF_PROG_QUERY command")
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 5f35f93dcab2..29ca9208dcfa 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1576,25 +1576,41 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
__u32 __user *prog_ids, u32 cnt)
{
struct bpf_prog **prog;
- u32 i = 0, id;
-
+ unsigned long err = 0;
+ u32 i = 0, *ids;
+ bool nospc;
+
+ /* users of this function are doing:
+ * cnt = bpf_prog_array_length();
+ * if (cnt > 0)
+ * bpf_prog_array_copy_to_user(..., cnt);
+ * so below kcalloc doesn't need extra cnt > 0 check, but
+ * bpf_prog_array_length() releases rcu lock and
+ * prog array could have been swapped with empty or larger array,
+ * so always copy 'cnt' prog_ids to the user.
+ * In a rare race the user will see zero prog_ids
+ */
+ ids = kcalloc(cnt, sizeof(u32), GFP_USER);
+ if (!ids)
+ return -ENOMEM;
rcu_read_lock();
prog = rcu_dereference(progs)->progs;
for (; *prog; prog++) {
if (*prog == &dummy_bpf_prog.prog)
continue;
- id = (*prog)->aux->id;
- if (copy_to_user(prog_ids + i, &id, sizeof(id))) {
- rcu_read_unlock();
- return -EFAULT;
- }
+ ids[i] = (*prog)->aux->id;
if (++i == cnt) {
prog++;
break;
}
}
+ nospc = !!(*prog);
rcu_read_unlock();
- if (*prog)
+ err = copy_to_user(prog_ids, ids, cnt * sizeof(u32));
+ kfree(ids);
+ if (err)
+ return -EFAULT;
+ if (nospc)
return -ENOSPC;
return 0;
}
This is a note to let you know that I've just added the patch titled
tpm: fix potential buffer overruns caused by bit glitches on the bus
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3be23274755ee85771270a23af7691dc9b3a95db Mon Sep 17 00:00:00 2001
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Date: Thu, 8 Feb 2018 12:28:08 -0800
Subject: tpm: fix potential buffer overruns caused by bit glitches on the bus
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 3be23274755ee85771270a23af7691dc9b3a95db upstream.
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: James Morris <james.morris(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_ch
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_ch
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
Patches currently in stable-queue which might be from jeremy.boone(a)nccgroup.trust are
queue-4.9/tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
This is a note to let you know that I've just added the patch titled
SMB3: Validate negotiate request must always be signed
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
smb3-validate-negotiate-request-must-always-be-signed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd Mon Sep 17 00:00:00 2001
From: Steve French <smfrench(a)gmail.com>
Date: Wed, 25 Oct 2017 15:58:31 -0500
Subject: SMB3: Validate negotiate request must always be signed
From: Steve French <smfrench(a)gmail.com>
commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.
According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
CC: Stable <stable(a)vger.kernel.org>
Acked-by: Ronnie Sahlberg <lsahlber.redhat.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1712,6 +1712,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;
rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
Patches currently in stable-queue which might be from smfrench(a)gmail.com are
queue-4.9/smb3-validate-negotiate-request-must-always-be-signed.patch
queue-4.9/cifs-enable-encryption-during-session-setup-phase.patch