This is a note to let you know that I've just added the patch titled
ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
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:
ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.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 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Date: Tue, 7 Nov 2017 11:37:07 +0100
Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
From: Roberto Sassu <roberto.sassu(a)huawei.com>
commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream.
Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters")
moved the call of ima_file_check() from may_open() to do_filp_open() at a
point where the file descriptor is already opened.
This breaks the assumption made by IMA that file descriptors being closed
belong to files whose access was granted by ima_file_check(). The
consequence is that security.ima and security.evm are updated with good
values, regardless of the current appraisal status.
For example, if a file does not have security.ima, IMA will create it after
opening the file for writing, even if access is denied. Access to the file
will be allowed afterwards.
Avoid this issue by checking the appraisal status before updating
security.ima.
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -320,6 +320,9 @@ void ima_update_xattr(struct integrity_i
if (iint->flags & IMA_DIGSIG)
return;
+ if (iint->ima_file_status != INTEGRITY_PASS)
+ return;
+
rc = ima_collect_measurement(iint, file, NULL, 0, ima_hash_algo);
if (rc < 0)
return;
Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are
queue-4.14/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch
This is a note to let you know that I've just added the patch titled
tpm-dev-common: Reject too short writes
to the 4.13-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-dev-common-reject-too-short-writes.patch
and it can be found in the queue-4.13 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 ee70bc1e7b63ac8023c9ff9475d8741e397316e7 Mon Sep 17 00:00:00 2001
From: Alexander Steffen <Alexander.Steffen(a)infineon.com>
Date: Fri, 8 Sep 2017 17:21:32 +0200
Subject: tpm-dev-common: Reject too short writes
From: Alexander Steffen <Alexander.Steffen(a)infineon.com>
commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream.
tpm_transmit() does not offer an explicit interface to indicate the number
of valid bytes in the communication buffer. Instead, it relies on the
commandSize field in the TPM header that is encoded within the buffer.
Therefore, ensure that a) enough data has been written to the buffer, so
that the commandSize field is present and b) the commandSize field does not
announce more data than has been written to the buffer.
This should have been fixed with CVE-2011-1161 long ago, but apparently
a correct version of that patch never made it into the kernel.
Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/tpm/tpm-dev-common.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -110,6 +110,12 @@ ssize_t tpm_common_write(struct file *fi
return -EFAULT;
}
+ if (in_size < 6 ||
+ in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) {
+ mutex_unlock(&priv->buffer_mutex);
+ return -EINVAL;
+ }
+
/* atomic tpm command send and result receive. We only hold the ops
* lock during this period so that the tpm can be unregistered even if
* the char dev is held open.
Patches currently in stable-queue which might be from Alexander.Steffen(a)infineon.com are
queue-4.13/tpm-dev-common-reject-too-short-writes.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_fintek: Fix finding base_port with activated SuperIO
to the 4.13-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:
serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch
and it can be found in the queue-4.13 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 fd97e66c5529046e989a0879c3bb58fddb592c71 Mon Sep 17 00:00:00 2001
From: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com>
Date: Tue, 17 Oct 2017 14:23:08 +0800
Subject: serial: 8250_fintek: Fix finding base_port with activated SuperIO
From: Ji-Ze Hong (Peter Hong) <hpeter(a)gmail.com>
commit fd97e66c5529046e989a0879c3bb58fddb592c71 upstream.
The SuperIO will be configured at boot time by BIOS, but some BIOS
will not deactivate the SuperIO when the end of configuration. It'll
lead to mismatch for pdata->base_port in probe_setup_port(). So we'll
deactivate all SuperIO before activate special base_port in
fintek_8250_enter_key().
Tested on iBASE MI802.
Tested-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com>
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com>
Reviewd-by: Alan Cox <alan(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_fintek.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -118,6 +118,9 @@ static int fintek_8250_enter_key(u16 bas
if (!request_muxed_region(base_port, 2, "8250_fintek"))
return -EBUSY;
+ /* Force to deactive all SuperIO in this base_port */
+ outb(EXIT_KEY, base_port + ADDR_PORT);
+
outb(key, base_port + ADDR_PORT);
outb(key, base_port + ADDR_PORT);
return 0;
Patches currently in stable-queue which might be from hpeter(a)gmail.com are
queue-4.13/serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch
This is a note to let you know that I've just added the patch titled
serial: omap: Fix EFR write on RTS deassertion
to the 4.13-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:
serial-omap-fix-efr-write-on-rts-deassertion.patch
and it can be found in the queue-4.13 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 2a71de2f7366fb1aec632116d0549ec56d6a3940 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sat, 21 Oct 2017 10:50:18 +0200
Subject: serial: omap: Fix EFR write on RTS deassertion
From: Lukas Wunner <lukas(a)wunner.de>
commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 upstream.
Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable
auto RTS upon manual RTS assertion and disable it on deassertion.
However it seems the latter was done incorrectly, it clears all bits in
the Extended Features Register *except* auto RTS.
Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling")
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -693,7 +693,7 @@ static void serial_omap_set_mctrl(struct
if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS))
up->efr |= UART_EFR_RTS;
else
- up->efr &= UART_EFR_RTS;
+ up->efr &= ~UART_EFR_RTS;
serial_out(up, UART_EFR, up->efr);
serial_out(up, UART_LCR, lcr);
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.13/serial-omap-fix-efr-write-on-rts-deassertion.patch
This is a note to let you know that I've just added the patch titled
ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
to the 4.13-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:
ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch
and it can be found in the queue-4.13 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 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Date: Tue, 7 Nov 2017 11:37:07 +0100
Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
From: Roberto Sassu <roberto.sassu(a)huawei.com>
commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream.
Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters")
moved the call of ima_file_check() from may_open() to do_filp_open() at a
point where the file descriptor is already opened.
This breaks the assumption made by IMA that file descriptors being closed
belong to files whose access was granted by ima_file_check(). The
consequence is that security.ima and security.evm are updated with good
values, regardless of the current appraisal status.
For example, if a file does not have security.ima, IMA will create it after
opening the file for writing, even if access is denied. Access to the file
will be allowed afterwards.
Avoid this issue by checking the appraisal status before updating
security.ima.
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -320,6 +320,9 @@ void ima_update_xattr(struct integrity_i
if (iint->flags & IMA_DIGSIG)
return;
+ if (iint->ima_file_status != INTEGRITY_PASS)
+ return;
+
rc = ima_collect_measurement(iint, file, NULL, 0, ima_hash_algo);
if (rc < 0)
return;
Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are
queue-4.13/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch
This is a note to let you know that I've just added the patch titled
ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
to the 3.18-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:
ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch
and it can be found in the queue-3.18 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 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001
From: Roberto Sassu <roberto.sassu(a)huawei.com>
Date: Tue, 7 Nov 2017 11:37:07 +0100
Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS
From: Roberto Sassu <roberto.sassu(a)huawei.com>
commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream.
Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters")
moved the call of ima_file_check() from may_open() to do_filp_open() at a
point where the file descriptor is already opened.
This breaks the assumption made by IMA that file descriptors being closed
belong to files whose access was granted by ima_file_check(). The
consequence is that security.ima and security.evm are updated with good
values, regardless of the current appraisal status.
For example, if a file does not have security.ima, IMA will create it after
opening the file for writing, even if access is denied. Access to the file
will be allowed afterwards.
Avoid this issue by checking the appraisal status before updating
security.ima.
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -297,6 +297,9 @@ void ima_update_xattr(struct integrity_i
if (iint->flags & IMA_DIGSIG)
return;
+ if (iint->ima_file_status != INTEGRITY_PASS)
+ return;
+
rc = ima_collect_measurement(iint, file, NULL, NULL);
if (rc < 0)
return;
Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are
queue-3.18/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch
On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Mark Rutland <mark.rutland(a)arm.com>
>
> commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
>
> It's possible for a user to deliberately trigger __dump_instr with a
> chosen kernel address.
>
> Let's avoid problems resulting from this by using get_user() rather than
> __get_user(), ensuring that we don't erroneously access kernel memory.
>
> Where we use __dump_instr() on kernel text, we already switch to
> KERNEL_DS, so this shouldn't adversely affect those cases.
>
> Fixes: 60ffc30d5652810d ("arm64: Exception handling")
[...]
This seems harmless, but I don't think it will fix the bug in 4.4
unless you also cherry-pick:
commit c5cea06be060f38e5400d796e61cfc8c36e52924
Author: Mark Rutland <mark.rutland(a)arm.com>
Date: Mon Jun 13 11:15:14 2016 +0100
arm64: fix dump_instr when PAN and UAO are in use
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
Hi---
Previously sent to stable was this patch, and it's made it into
Linus's tree for 4.16. It's a rather urgent data corruption issue
that affects at minimum bcache but possibly other block subsystems.
Several users have lost data. The issue was introduced in the 4.15
branch by 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer
and partitions index").
I'd really appreciate anything that can be done to get this into a
stable 4.15 release soon.
Thanks--
Mike
On Tue, Nov 21, 2017 at 06:34:54PM +0200, Leon Romanovsky wrote:
> On Tue, Nov 21, 2017 at 09:04:42AM -0700, Jason Gunthorpe wrote:
> > On Tue, Nov 21, 2017 at 09:37:27AM -0600, Daniel Jurgens wrote:
> >
> > > The only warning that would make sense is if the mixed ports aren't
> > > all IB or RoCE. As you note, CX-3 can mix those two, we don't want to
> > > see warnings about that.
> >
> > I would really like to see cx3 be changed to not do that, then we
> > could finalize this issue upstream: All device ports must be the same
> > protocol.
>
> I don't see the point of such artificial limitation, the users who
> brought CX-3 have option to work in mixed mode and IMHO it is not right
> to deprecate such ability just because it is hard for us to code for it.
I don't really think it is really too user visible.. Only the device
and port number change, but only if running in mixed mode.
It is not just 'hard for us' it is impossible to reconcile the
differences between ports when enforcing device level things.
This keeps coming up again and again..
Jason
On 21/11/2017 15:22, Leon Romanovsky wrote:
> On Tue, Nov 21, 2017 at 12:44:10PM +0200, Mark Bloch wrote:
>> Hi,
>>
>> On 21/11/2017 12:26, Leon Romanovsky wrote:
>>> From: Daniel Jurgens <danielj(a)mellanox.com>
>>>
>>> For now the only LSM security enforcement mechanism available is
>>> specific to InfiniBand. Bypass enforcement for non-IB link types.
>>> This fixes a regression where modify_qp fails for iWARP because
>>> querying the PKEY returns -EINVAL.
>>>
>>> Cc: Paul Moore <paul(a)paul-moore.com>
>>> Cc: Don Dutile <ddutile(a)redhat.com>
>>> Cc: stable(a)vger.kernel.org
>>> Reported-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
>>> Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs")
>>> Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams")
>>> Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
>>> Reviewed-by: Parav Pandit <parav(a)mellanox.com>
>>> Tested-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
>>> Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
>>> ---
>>> drivers/infiniband/core/security.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c
>>> index 23278ed5be45..314bf1137c7b 100644
>>> --- a/drivers/infiniband/core/security.c
>>> +++ b/drivers/infiniband/core/security.c
>>> @@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
>>>
>>> int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
>>> {
>>> + u8 i = rdma_start_port(dev);
>>> + bool is_ib = false;
>>> int ret;
>>>
>>> + while (i <= rdma_end_port(dev) && !is_ib)
>>> + is_ib = rdma_protocol_ib(dev, i++);
>>> +
>>
>> What happens if we have mixed port types?
>
> We will have is_ib set and qp_sec will be allocated on device layer and
> not on port level, but because pkeys are IB specific term (at least, I
> didn't find any mentioning in RoCE spec), the modify_qp won't query
> for PKEYS.
>
What is port level for qp_sec?
I just gave mlx4 as an example, but I was talking more about the ability of the RDMA
subsystem to support mixed port types, so in this case, if in the future a vendor
will come with an ib_device with 2 ports, one is IB and one is iWARP bad things will happen.
>> I believe mlx4 can expose two ports where each port uses a different ll protocol.
>> Was that changed?
>
> It is still true.
>
>>
>>> + /* If this isn't an IB device don't create the security context */
>>> + if (!is_ib)
>>> + return 0;
>>> +
>>> qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
>>> if (!qp->qp_sec)
>>> return -ENOMEM;
>>>
>>
>> Mark.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo(a)vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Mark
From: Yazen Ghannam <yazen.ghannam(a)amd.com>
[Upstream commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071]
The AMD severity grading function was introduced in kernel 4.1. The
current logic can possibly give MCE_AR_SEVERITY for uncorrectable
errors in kernel context. The system may then get stuck in a loop as
memory_failure() will try to handle the bad kernel memory and find it
busy.
Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD
systems.
After:
b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
was accepted in v4.6, this issue was masked because of the tail-end attempt
at kernel mode recovery in the #MC handler.
However, uncorrectable errors IN_KERNEL context should always be considered
unrecoverable and cause a panic.
Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com>
Cc: <stable(a)vger.kernel.org> # 4.1.x, 4.4.x
Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function)
---
Same as
d65dfc81bb38 ("x86/MCE/AMD: Always give panic severity for UC errors in kernel context")
but fixed up to apply to v4.1 and v4.4 stable branches.
arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index 9c682c222071..a9287f0f06f2 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -200,6 +200,9 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
if (m->status & MCI_STATUS_UC) {
+ if (ctx == IN_KERNEL)
+ return MCE_PANIC_SEVERITY;
+
/*
* On older systems where overflow_recov flag is not present, we
* should simply panic if an error overflow occurs. If
@@ -207,10 +210,6 @@ static int mce_severity_amd(struct mce *m, int tolerant, char **msg, bool is_exc
* to at least kill process to prolong system operation.
*/
if (mce_flags.overflow_recov) {
- /* software can try to contain */
- if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL))
- return MCE_PANIC_SEVERITY;
-
/* kill current process */
return MCE_AR_SEVERITY;
} else {
--
2.14.1
This is a note to let you know that I've just added the patch titled
vlan: fix a use-after-free in vlan_device_event()
to the 3.18-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:
vlan-fix-a-use-after-free-in-vlan_device_event.patch
and it can be found in the queue-3.18 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 Tue Nov 21 15:37:44 CET 2017
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Thu, 9 Nov 2017 16:43:13 -0800
Subject: vlan: fix a use-after-free in vlan_device_event()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 052d41c01b3a2e3371d66de569717353af489d63 ]
After refcnt reaches zero, vlan_vid_del() could free
dev->vlan_info via RCU:
RCU_INIT_POINTER(dev->vlan_info, NULL);
call_rcu(&vlan_info->rcu, vlan_info_rcu_free);
However, the pointer 'grp' still points to that memory
since it is set before vlan_vid_del():
vlan_info = rtnl_dereference(dev->vlan_info);
if (!vlan_info)
goto out;
grp = &vlan_info->grp;
Depends on when that RCU callback is scheduled, we could
trigger a use-after-free in vlan_group_for_each_dev()
right following this vlan_vid_del().
Fix it by moving vlan_vid_del() before setting grp. This
is also symmetric to the vlan_vid_add() we call in
vlan_device_event().
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Fixes: efc73f4bbc23 ("net: Fix memory leak - vlan_info struct")
Cc: Alexander Duyck <alexander.duyck(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Girish Moodalbail <girish.moodalbail(a)oracle.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Girish Moodalbail <girish.moodalbail(a)oracle.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/8021q/vlan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -376,6 +376,9 @@ static int vlan_device_event(struct noti
dev->name);
vlan_vid_add(dev, htons(ETH_P_8021Q), 0);
}
+ if (event == NETDEV_DOWN &&
+ (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER))
+ vlan_vid_del(dev, htons(ETH_P_8021Q), 0);
vlan_info = rtnl_dereference(dev->vlan_info);
if (!vlan_info)
@@ -420,9 +423,6 @@ static int vlan_device_event(struct noti
break;
case NETDEV_DOWN:
- if (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)
- vlan_vid_del(dev, htons(ETH_P_8021Q), 0);
-
/* Put all VLANs for this dev in the down state too. */
vlan_group_for_each_dev(grp, i, vlandev) {
flgs = vlandev->flags;
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-3.18/ipv6-dccp-do-not-inherit-ipv6_mc_list-from-parent.patch
queue-3.18/vlan-fix-a-use-after-free-in-vlan_device_event.patch
This is a note to let you know that I've just added the patch titled
tcp: do not mangle skb->cb[] in tcp_make_synack()
to the 3.18-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:
tcp-do-not-mangle-skb-cb-in-tcp_make_synack.patch
and it can be found in the queue-3.18 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 Tue Nov 21 15:37:44 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 2 Nov 2017 12:30:25 -0700
Subject: tcp: do not mangle skb->cb[] in tcp_make_synack()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 3b11775033dc87c3d161996c54507b15ba26414a ]
Christoph Paasch sent a patch to address the following issue :
tcp_make_synack() is leaving some TCP private info in skb->cb[],
then send the packet by other means than tcp_transmit_skb()
tcp_transmit_skb() makes sure to clear skb->cb[] to not confuse
IPv4/IPV6 stacks, but we have no such cleanup for SYNACK.
tcp_make_synack() should not use tcp_init_nondata_skb() :
tcp_init_nondata_skb() really should be limited to skbs put in write/rtx
queues (the ones that are only sent via tcp_transmit_skb())
This patch fixes the issue and should even save few cpu cycles ;)
Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Christoph Paasch <cpaasch(a)apple.com>
Reviewed-by: Christoph Paasch <cpaasch(a)apple.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/tcp_output.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2911,13 +2911,8 @@ struct sk_buff *tcp_make_synack(struct s
tcp_ecn_make_synack(req, th, sk);
th->source = htons(ireq->ir_num);
th->dest = ireq->ir_rmt_port;
- /* Setting of flags are superfluous here for callers (and ECE is
- * not even correctly set)
- */
- tcp_init_nondata_skb(skb, tcp_rsk(req)->snt_isn,
- TCPHDR_SYN | TCPHDR_ACK);
-
- th->seq = htonl(TCP_SKB_CB(skb)->seq);
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ th->seq = htonl(tcp_rsk(req)->snt_isn);
/* XXX data is queued and acked as is. No buffer/window check */
th->ack_seq = htonl(tcp_rsk(req)->rcv_nxt);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/tcp-do-not-mangle-skb-cb-in-tcp_make_synack.patch
queue-3.18/ipv6-dccp-do-not-inherit-ipv6_mc_list-from-parent.patch
This is a note to let you know that I've just added the patch titled
sctp: do not peel off an assoc from one netns to another one
to the 3.18-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:
sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch
and it can be found in the queue-3.18 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 Tue Nov 21 15:37:44 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Tue, 17 Oct 2017 23:26:10 +0800
Subject: sctp: do not peel off an assoc from one netns to another one
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ]
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
socket$inet6_sctp()
bind$inet6()
sendto$inet6()
unshare(0x40000000)
getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <chunwang(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4466,6 +4466,10 @@ int sctp_do_peeloff(struct sock *sk, sct
struct socket *sock;
int err = 0;
+ /* Do not peel off from one netns to another one. */
+ if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
+ return -EINVAL;
+
if (!asoc)
return -EINVAL;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch
This is a note to let you know that I've just added the patch titled
netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed
to the 3.18-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:
netfilter-ipvs-clear-ipvs_property-flag-when-skb-net-namespace-changed.patch
and it can be found in the queue-3.18 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 Tue Nov 21 15:37:44 CET 2017
From: Ye Yin <hustcat(a)gmail.com>
Date: Thu, 26 Oct 2017 16:57:05 +0800
Subject: netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed
From: Ye Yin <hustcat(a)gmail.com>
[ Upstream commit 2b5ec1a5f9738ee7bf8f5ec0526e75e00362c48f ]
When run ipvs in two different network namespace at the same host, and one
ipvs transport network traffic to the other network namespace ipvs.
'ipvs_property' flag will make the second ipvs take no effect. So we should
clear 'ipvs_property' when SKB network namespace changed.
Fixes: 621e84d6f373 ("dev: introduce skb_scrub_packet()")
Signed-off-by: Ye Yin <hustcat(a)gmail.com>
Signed-off-by: Wei Zhou <chouryzhou(a)gmail.com>
Signed-off-by: Julian Anastasov <ja(a)ssi.bg>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/skbuff.h | 7 +++++++
net/core/skbuff.c | 1 +
2 files changed, 8 insertions(+)
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3117,6 +3117,13 @@ static inline void nf_reset_trace(struct
#endif
}
+static inline void ipvs_reset(struct sk_buff *skb)
+{
+#if IS_ENABLED(CONFIG_IP_VS)
+ skb->ipvs_property = 0;
+#endif
+}
+
/* Note: This doesn't put any conntrack and bridge info in dst. */
static inline void __nf_copy(struct sk_buff *dst, const struct sk_buff *src,
bool copy)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4069,6 +4069,7 @@ void skb_scrub_packet(struct sk_buff *sk
if (!xnet)
return;
+ ipvs_reset(skb);
skb_orphan(skb);
skb->mark = 0;
}
Patches currently in stable-queue which might be from hustcat(a)gmail.com are
queue-3.18/netfilter-ipvs-clear-ipvs_property-flag-when-skb-net-namespace-changed.patch
This is a note to let you know that I've just added the patch titled
net/sctp: Always set scope_id in sctp_inet6_skb_msgname
to the 3.18-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:
net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch
and it can be found in the queue-3.18 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 Tue Nov 21 15:28:16 CET 2017
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Wed, 15 Nov 2017 22:17:48 -0600
Subject: net/sctp: Always set scope_id in sctp_inet6_skb_msgname
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit 7c8a61d9ee1df0fb4747879fa67a99614eb62fec ]
Alexandar Potapenko while testing the kernel with KMSAN and syzkaller
discovered that in some configurations sctp would leak 4 bytes of
kernel stack.
Working with his reproducer I discovered that those 4 bytes that
are leaked is the scope id of an ipv6 address returned by recvmsg.
With a little code inspection and a shrewd guess I discovered that
sctp_inet6_skb_msgname only initializes the scope_id field for link
local ipv6 addresses to the interface index the link local address
pertains to instead of initializing the scope_id field for all ipv6
addresses.
That is almost reasonable as scope_id's are meaniningful only for link
local addresses. Set the scope_id in all other cases to 0 which is
not a valid interface index to make it clear there is nothing useful
in the scope_id field.
There should be no danger of breaking userspace as the stack leak
guaranteed that previously meaningless random data was being returned.
Fixes: 372f525b495c ("SCTP: Resync with LKSCTP tree.")
History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Reported-by: Alexander Potapenko <glider(a)google.com>
Tested-by: Alexander Potapenko <glider(a)google.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -805,6 +805,8 @@ static void sctp_inet6_skb_msgname(struc
if (ipv6_addr_type(&addr->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) {
struct sctp_ulpevent *ev = sctp_skb2event(skb);
addr->v6.sin6_scope_id = ev->iif;
+ } else {
+ addr->v6.sin6_scope_id = 0;
}
}
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-3.18/net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch